This really sort of opens the door for auto types in C. I know 'auto' is
currently a reserved word like 'register'; maybe 'var' would be a good
substitute.

On Tue, Mar 10, 2020 at 1:13 AM Jens Gustedt via Liaison <
liaison_at_[hidden]> wrote:

> J,
>
> I am merely talking about C, I wouldn't know too well for C++.
>
> No, not at all, you are reversing the implications. If you already
> have an object of the structure type, `E1.E2` should be fine. But if
> you have a pointer to an untyped object (storage instance as we tend
> to call it know), `E1→E2` does not pretend that this object already
> has acquired the type, yet. Such a typed object clearly only springs
> into life, once you have initialized all the members with such an
> access.
>
> the standard actually says like 'if it's a qualified type, then it's
resulting type is the member's type', but does not specify what to do if it
is an unqualified type; most compilers throw an error on this; and I don't
know any that could take a wild guess and work.


> And many of the aliasing analysis in C is bound to the effective type,
> so if you access objects for which the effective type is not yet
> determined, aliasing analysis may go wrong.
>
And this is what made me go investigate _Generic() (which is gross)...but;
having a consistent operator '.' which can accept either a struct passed by
value, or a struct passed by pointer, would allow the type to be qualified
later, from where the function is invoked, using the type of the parameter
passed there to determine the real type.


>
> For C++ this is probably different because people are not supposed to
> use `malloc` but `new` which launches a constructor, but at the
> extreme you still have the same or similar rules, if I remember
> correctly.
>
but new still requires a qualified type ahead of time so it can know what
size to allocate; allowing to declare just in a function context etc...
All of the existing information about where(how) the thing was allocated
should really still be retained through the chain of operations on it; at
least from a static analysis point of view. It's arguable that after the
second time you've passed a &staticStruct that sort of information is
really lost and the routine can't really know if it was dynamic or static.


> (And I still don't like it.)
>
> Thanks
> Jens
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536 ::
> :: :::::::::::::::::::::: gsm France : +33 651400183 ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2020/03/0065.php
>