digitalmars.dip.ideas - Separation on assignment [re: tuples]
- monkyyy (18/18) May 14 ```d
- Timon Gehr (6/27) May 14 I think it is an interesting and worthwhile idea to do it this way.
- Nick Treleaven (6/12) May 15 Unpacking into `alias`es is not included in the DIP, but it might
- monkyyy (18/30) May 15 I mean this as a major difference then yours
- Nick Treleaven (11/22) May 16 UDAs should be implemented, I meant a temporary error (done &
```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.
May 14
Timon Gehr <timon.gehr gmx.ch> 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 14
On Wednesday, 14 May 2025 at 18:06:26 UTC, monkyyy wrote:```d auto (a,b)=... enum (a,b)=... alias (a,b)=... immutable someuda nogc auto (a,b)=... ```Unpacking into `alias`es 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).
May 15
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: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.```d auto (a,b)=... enum (a,b)=... alias (a,b)=... immutable someuda nogc auto (a,b)=... ```Unpacking into `alias`es 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).
May 15
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: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.Unpacking into `alias`es 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 yoursThe 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.
May 16