On Fri, Dec 20, 2019 at 12:03 PM J Decker <d3c...@gmail.com> wrote: > > > On Fri, Dec 20, 2019 at 11:59 AM J Decker <d3c...@gmail.com> wrote: > >> >> >> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer <fwei...@redhat.com> >> wrote: >> >>> * J. Decker: >>> >>> > Here's the gist of what I would propose... >>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >>> > >>> > In C, there are two operators . and -> used to access members of >>> struct and >>> > union types. These operators are specified such that they are always >>> paired >>> > in usage; for example, if the left hand expression is a pointer to a >>> struct >>> > or union, then the operator -> MUST be used. There is no occasion >>> where . >>> > and -> may be interchanged, given the existing specification. >>> >>> This is incompatible with C++. I don't think it's worthwhile to change >>> C in this way. >>> >> >> ya, while I only just saw this, I thought shortly after posting that c++ >> compatibility might be an issue; and they have separate operators overrides >> for -> and . (which V8 uses such that `Local<Object> lo;` `lo.IsEmpty();` >> and `lo->Get()` are interchangeable. >> >> However, if not specifically overridden it could be possible to make a >> similar change there. (and conversely not having the operator support the >> C++ back port wouldn't be an issue). It's still an error in the native >> language context to use '.' on a pointer or '->' on a class/struct... and >> the modification is really a patch to that error to just do the other >> thing... >> > and add -> on references? >
My first patch was to make the . and -> interchangeable; it could be more specifically to promote '.' to be either; with the intent to deprecate -> (in like 2119). This might simplify the scope of modification to C++; to just augment the default '.' to behave as -> on a native pointer to a struct/class/union ( I'm not sure how the new safe_ptr templated things end up reacting, I'd imagine they provide operator overloads, which would take precedence... ) > > >> >> >> >>> >>> Thanks, >>> Florian >>> >>>
