On Sat, Jan 26, 2013 at 11:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir = Batov wrote:
On Saturday, January 26= , 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <= jmck...@gmail.com> wrote:
> ...
Do you think we should back away from all the pointer-ish interface
parts and move more towards container-ish?=A0

"We" are reading the 3rd revision of the document d= escribing the facility which has been in heavy use for a while and which ha= s already been submitted for standardization. "we should back away fro= m all the pointer-ish interface"... Is it a serious question or a tease?
=A0
=A0

No it should not. I'm not particularly enamoured with= `operator*`, but `operator[]` makes no sense at all. Why not just `value` = (or `get` for those who like that)? Do we really need an operator at all?

Uhm, because we need to dereference 'option= al' and the language has a dereferencing operator (op*) which happens t= o be used everywhere else to dereference.

That's called "assuming the conclusion" or "begging = the question".

Why beg the question when y= ou can ask the question you are begging for? :-) Seriously though I was try= ing to convey my impression that the thread (which I considered the questio= n to be the culmination of) went on such a tangent that it somewhat lost *p= ractical* value for the class under consideration/discussion taking into ac= count its current state progress so far. I might be wrong as usual.

The question in this case bei= ng whether `optional` should be thought of as being like a pointer. IE: tha= t optional is a thing that can be dereferenced.

I fail to see the practical value of trying so = hard and squeezing 'optional' into Procrustean bed of some other co= ncept be that a container, a pointer, or anything else. We can debate endle= ssly similarities and differences. However, 'optional' serves a cer= tain need and exists for a reason. If 'optional' was a container, t= hen an existing container would do just fine. If 'optional' was a p= ointer, then an existing pointer would be used instead. Jack and Jill are s= imilar from one angle and different from another. Do we *have* to label Jac= k "a Jill with a dongle" and force him to wear dress? I hope you = get my drift.
=A0

You don't dereference an o= ptional any more than you dereference a std::vector. You only dereference <= i>references (it's right there in the name),

Uhm, I strongly feel that you treat naming and the la= nguage wa-a-a-y to rigidly. You are not only "derail rails" and &= quot;debunk bunks". As for "dereferencing" then it assumes i= ndirection. In fact, Microsoft even lists/names op* as ans indirection oper= ator:

http://msdn.microsoft.com/en-us/library/fw63e3c3%28v=3Dvs.71%29.a= spx

Obviously, one can apply dereferencing/indirection everywher= e it makes sense. Most notably the proxy pattern which 'optional' i= s a representative of.
=A0

and one of the most import= ant aspects of optional is that it has value semantics, not referenc= e semantics. Optional is not a reference, so it doesn't make sense to u= se reference-like operations on it.

Well, again, I feel that for one reason or anot= her you are forcing yourself in a black&white world when real life is m= ulti-faceted and multi-colored.=A0
=A0

Dereferencing an optional makes no more sense than dereferencing an in= teger.

Uhm, how does comparison with an '= ;integer' prove anything? Do 'optional' and 'integer' h= ave much in common? A real, say, horse has more in common with a plastic fi= gurine mimicking a horse. Still, I do not dare to say that feeding a horse = makes no more sense than feeding a plastic figurine.=A0 =A0

=A0

There is no "a= ll the pointer-ish interface"; there's only `operator*. That's= the only part of optional that is like a pointer (OK, the `explicit operat= or bool` too, but that's hardly unique to pointers); everything else wo= rks differently from pointers.

There is nothing "pointer-ish" about = the operator called a dereferencing operator.
=
There is only one C++ type upon which applying uniary operator* results= in guaranteed dereferencing. And those are pointers.

I am not sure how to respond to this one. I am = quite lost about "guaranteed" dereferencing and the statement is = plain wrong in the context of C++.

=A0

Pointers may not be the only things you can use uniary operator* on, b= ut the user expectation of it is very clear: dereferencing a reference type= .. std::ref is a reference type. std::unique_ptr is a reference type.

"user expectation of it is very clear"= ;... I usually throw in the towel when people start speaking for the whole = humanity or considerable chunks of it. I have no crystal ball or mystic pow= ers to represent such a wide audience and, therefore, cannot argue on such = a high level. So, regretfully, I have to give up arguing my point. It was f= un though.

=A0

std::optional is not.<= br>

Customization (oveloading) of that op* together with the other derefer= encing op->() is "important to a class of interesting programs"= ; (as Stroustrup puts it).

No, the ability= to fetch the value from an optional is important. Exactly how you do that = is dealer's choice.

--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@is= ocpp.org.

Visit this group at http://groups.google.com/a/isocpp= ..org/group/std-proposals/?hl=3Den.
=A0
=A0