July 20, 2020 Re: alias restriction??! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 Re: alias restriction??! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carl Sturtivant | 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.
|
Copyright © 1999-2021 by the D Language Foundation