Okay for discussion like questions I will mail my future questions to the
stddiscussion mailing list. Thanks for the info.

On Tue, 9 May 2023, 22:27 Brian Bi, <bbi5291_at_[hidden]> wrote:

> First, please note that you have sent your question to the wrong list. You
> should use std-discussion_at_[hidden] to ask questions about the
> standard. std-proposals_at_[hidden] is for, well, proposals, but you
> should keep in mind that its utility is limited, because the set of people
> who read it is not representative of the set of people who will actually
> vote on a formal proposal if you were to submit it for consideration in a
> committee mailing.
>
> On Tue, May 9, 2023 at 12:25 PM Sean Mayard via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> @jonathan
>>
>> [expr.pre] also says *Overloaded operators obey the rules for syntax and
>> evaluation order specified in* [expr.compound]
>> <https://timsong-cpp.github.io/cppwp/n4868/expr.compound>...
>>
>> So even though [expr.compound] is for built in types, [expr.compound]
>> also applies to overloaded operators?
>>
>
> In terms of syntax and evaluation order, yes (as [expr.pre] says). In
> terms of semantics, no.
>
>
>>
>> On Tue, 9 May 2023, 21:36 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>>
>>>
>>>
>>> On Tue, 9 May 2023 at 15:42, Sean Mayard <seanmayard_at_[hidden]> wrote:
>>>
>>>> Look at the previous sentence.
>>>>
>>>>
>>>> Okay, so the previous sentence says "For the first option (dot) the
>>>> first expression shall be a glvalue.
>>>> <https://timsong-cpp.github.io/cppwp/n4868/expr.ref#2.sentence-1> For
>>>> the second option (arrow) the first expression shall be a prvalue having *pointer
>>>> type*.
>>>> <https://timsong-cpp.github.io/cppwp/n4868/expr.ref#2.sentence-2> " By
>>>> pointer type they mean built-in pointer type and not smart pointer type.
>>>>
>>>
>>> Yes, smart pointers have class type. There are no "smart pointer types"
>>> in the type taxonomy of C++, that's just an idiomatic name for class types
>>> with a pointer-like API.
>>>
>>> But it's irrelevant, [expr.pre] means the whole paragraph only applies
>>> to the built-in operator, not an overloaded operator. There are no built-in
>>> -> operators for smart pointer types, only operator->() overloads.
>>>
>>>
>>>
>>>
>>>> On Tue, 9 May 2023 at 18:35, Jonathan Wakely <cxx_at_[hidden]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, 9 May 2023 at 13:10, Sean Mayard via Std-Proposals <
>>>>> std-proposals_at_[hidden]> wrote:
>>>>>
>>>>>> I read [expr.ref#2] which includes the following sentence:
>>>>>>
>>>>>> > *The expression E1->E2 is converted to the equivalent form
>>>>>> (*(E1)).E2*
>>>>>>
>>>>>> My question is, does this mean that "every" expression that has the
>>>>>> form *E1->E2* will be converted to *(*(E1)).E2. *I mean it is not
>>>>>> clear to me in what situations/contexts does the above sentence hold?
>>>>>>
>>>>>> For example, suppose we have a class that overloads *operator* *but
>>>>>> does not overload *operator->* then if we use *operator-> *with an
>>>>>> object of that class type, then that expression will be first converted to
>>>>>> *(*(E1)).E2* form?
>>>>>>
>>>>>> #include <iostream> struct A { int foo = 1, bar =2;};struct B { A a{}; A& operator* () { return a; }}; int main(){ B b{}; int x = b->foo; //i know this will give error because there is no overloaded operator-> //but according to [expr.ref#2] shouldn't b->foo be first converted to (*(b)).foo //and then the overloaded operator* should be used }
>>>>>>
>>>>>>
>>>>>> As you can see in the above program, `b->foo;` gives an error because
>>>>>> the class `B` has not overloaded *operator-> *. But according to
>>>>>> [expr.ref#2] the expression *b->foo *should be converted to *(*(b)).foo
>>>>>> *and then the *operator* *could be used.
>>>>>>
>>>>>> So I want to know what exactly does [expr.ref#2] mean when it said " *The
>>>>>> expression E1->E2 is converted to the equivalent form (*(E1)).E2* ".
>>>>>> Does this conversion supposed to happen only after `E1->E2` is valid or
>>>>>> before. Is a CWG issue required for this or I just did not read/interpret
>>>>>> it correctly.
>>>>>>
>>>>>
>>>>> See [expr.pre] which explains that the rules in Clause [expr] apply to
>>>>> the built-in operators, not to overloaded operators.
>>>>>
>>>>> "Subclause 7.6 defines the effects of operators when applied to types
>>>>> for which they have not been overloaded." (and also the note before that).
>>>>>
>>>>>
>>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
> --
> *Brian Bi*
>