July 20, 2020
On Sunday, 19 July 2020 at 20:46:19 UTC, Steven Schveighoffer wrote:
> On 7/19/20 4:21 PM, Carl Sturtivant wrote:
>> 
>> Perhaps what's needed is something more that is less than allowing aliases for expressions in the wide sense you suggest here.
>
> I agree. Something not yet mentioned is that aliases provide direct access to the symbols for the purposes of looking at attributes -- something that a wrapper function doesn't provide.
>
> The question is: how do you restrict it to explicit data items within a specific aggregate without parsing arbitrary expressions?

Well perhaps you do parse a "constant-offset expression" i.e. syntactically dotted with constant indexes, like name1.name2[constant].name3 and then later there's a semantic check that the "constant-offset expression" involves no indirections when an offset into the top level object is computed. Then it's treated like any other attribute of a struct with a known offset.
July 20, 2020
On Monday, 20 July 2020 at 17:24:56 UTC, Carl Sturtivant wrote:
> Well perhaps you do parse a "constant-offset expression" i.e. syntactically dotted with constant indexes, like name1.name2[constant].name3 and then later there's a semantic check that the "constant-offset expression" involves no indirections when an offset into the top level object is computed. Then it's treated like any other attribute of a struct with a known offset.

Perhaps this could also work for a class at the top with recursively embedded structs and value arrays.
1 2
Next ›   Last »