Separation on assignment [re: tuples]

May 14

monkyyy

May 15

Timon Gehr

May 15

Nick Treleaven

May 15

monkyyy

May 16

Nick Treleaven

On 5/14/25 20:06, monkyyy wrote: > ```d > auto (a,b)=... > enum (a,b)=... > alias (a,b)=... > immutable @someuda @nogc auto (a,b)=... > ``` > > Assign-like statements with ()'s will be lowered to an operator overload. > > `auto (a,b)=foo;` => `auto a=foo.opSeperate!(0,2)`, `auto b=foo.opSeperate!(1,2)` > > where opSeparate is intended to have the header `auto opSeperate(int position,int total)` for tuples. > > --- > > I believe having the total of user defined id's will in the end be preferable for api design, consider how ranges currently work with foreach, where you cant define both a `foreach(index,element;...)` and `foreach(element;...)` at the same time. I think it is an interesting and worthwhile idea to do it this way. While it has a few benefits, a drawback compared to an `auto opUnpack()=>tuple(a,b);` is that the implementation will in general be more annoying, in particular, you cannot share preprocessing. (Passing the total number of elements could optionally also be added to `opUnpack`.)

May 15

Re: Separation on assignment [re: tuples]

Posted by monkyyy
in reply to Nick Treleaven

Permalink

monkyyy

Posted in reply to Nick Treleaven

Permalink

On Thursday, 15 May 2025 at 16:22:43 UTC, Nick Treleaven wrote:

On Wednesday, 14 May 2025 at 18:06:26 UTC, monkyyy wrote:

auto (a,b)=...
enum (a,b)=...
alias (a,b)=...
immutable @someuda @nogc auto (a,b)=...

Unpacking into aliases is not included in the DIP, but it might be a nice future enhancement. The other 3 lines would work except UDAs (@someuda) is not currently supported by the implementation. (I'll add an error for that as I currently get a segfault).

I mean this as a major difference then yours

((x,y), z){ ... } is lowered to (__arg0, z){ auto (x,y) = __arg0; ...}. In general, it preserves and copies storage classes from the parameter to the unpack declaration in the function body.

ref storage class is copied outwards, e.g. if you do ((ref a,b), c){ ... } that gets lowered to (ref __arg0, c){ (ref a,auto b) = __arg0; ... }.

The lowering im suggesting is lazier but I think would naturally allow aliases and enums

Idk about udas cause... compiler dev stuff I now nothing about, but if it was mixin(assimentstart~" "~id[I]~"="~assignfrom.opSeperate!(I,Total)) I think those udas could be copy and pasted depending on how close to the raw strings the code was. If not, I dont actually care(I hate the labling), auto, alias, enum would be good.

On Thursday, 15 May 2025 at 22:02:07 UTC, monkyyy wrote:

On Thursday, 15 May 2025 at 16:22:43 UTC, Nick Treleaven wrote:

I mean this as a major difference then yours

UDAs should be implemented, I meant a temporary error (done & Timon merged it). However implementing UDA support now might complicate the diff to be reviewed if/when it's submitted to mainline dmd. The reason is that the compiler's definition of storage classes is different from the grammar spec, i.e. the compiler considers UDAs to be separate AFAICT.

The lowering im suggesting is lazier but I think would naturally allow aliases and enums

enum is supported:

static or enum can be applied to the whole declaration, but not to individual components.

alias is a separate kind of declaration to a variable declaration in both the grammar and the compiler, so again I don't think this should be supported in the initial PR to dmd.

Forums