On Saturday, 24 August 2024 at 17:56:21 UTC, monkyyy wrote:
> On Saturday, 24 August 2024 at 16:36:17 UTC, Manu wrote:
>> alias x = s.tupleof; // this works
>> alias y = s.tupleof[0]; // this is a compile error?!
>>
>> How can embarrassing edge cases like this still exist in the
>> language today? I'm just reacquainting myself with all the
>> reasons that I've had such a hard time trying to convince my
>> colleagues to take D seriously for such a long time.
>>
>> 😫
>
> ```d
> auto tuple(T...)(T args){
> struct Tuple{
> enum istuple=true;
> T me; alias me this;
> }
> return Tuple(args);
> }
> unittest{
> auto foo=tuple(1,"hi");
> assert(foo[0]==1);
> assert(foo[1]=="hi");
> auto bar=tuple();
> }
> auto totuple(T)(T a) if(is(typeof(a.istuple)))=>a;
> auto totuple(T)(T a) if( ! is(typeof(a.istuple)))=>tuple(a);
> auto maybetuple(T...)(T a){
> static if(T.length==1){
> return a[0];
> } else {
> return tuple(a);
> }}
> ```
>
> Could be fixed with a better std.meta
D needs native tuple, not this mess
Facts.
This is a really old drum to beat on... but maybe we need to start pounding it again.
It's not strictly this simple though; I think there's a lot of work up-front. We don't really even know what a tuple is, or even what "kinds" of things the language can express...
Like, there's more than types and values. There's symbol aliases, which may or may not carry an instance reference with them, declaration aliases, which may carry names and properties like storage class, there's sometimes expression aliases, there's potentially attributes, and heaps of other stuff that exists outside the language; like storage class, which doesn't seem to have any presence in the language at all; it's queried with a __traits and comically tells you those facts as string literals! I think this space might be the heart and soul of D's foundational issues, and as such, it's excruciatingly hard to make corrections.
Like, from my example above, what even IS `s.tupleof`? It's some kind of list of what kind of thing? Direct symbol references to members of a live instance?
If s.tupleof can populate a list with that kind of thing, why doesn't this work:
struct S
{
int x, y;
}
struct T
{
S s;
int i;
alias a = i; // works
alias b = s.x; // Doesn't work? Why?
}
It seems like s.tupleof presents that there are semantics in the language to express this sort of thing, but it's not clear what to call that.
Likewise in my example above:
alias a = s.tupleof; // this can hold the list of references, which seem to carry around their instance reference with them
alias b =
s.tupleof[0]; // this emits a surprising error message:
error : alias `b` cannot alias an expression `AliasSeq!(s.x, s.y)[0]`
So, that 'list' I mention; does this error message imply that this list given by `tupleof` is an AliasSeq? What exactly IS an AliasSeq? What is the actual set of things that it can hold?
If tupleof is an AliasSeq, then what's going on here:
alias c = AliasSeq!(s.tupleof);
alias d = c[0]; // the error is now gone??
I think a good indication that this whole space is profoundly troubled when classic patterns like this emerge:
template T(alias X) { use X } // oh no you don't, alias is very opinionated! you'll need this instead:
template T(X...) if (X.length == 1) { use X[0] }
Who here can honestly say they thought that was a reasonable thing to write the first time they encountered that piece of comedy gold?
... and why are they even different things? If an AliasSeq isn't a sequence of aliases, what is it? What are people supposed to imagine it is?
These are rhetorical questions, put yourself in an outside perspective; I know you can 'explain' it. I used to be able to explain it, but it turns out that with a few years off from D that toxicity in my mind seems to have subsided to some degree! I'm reacquainting myself with a sea of nonsense that I kinda just settled into with sufficient sustained exposure.
No matter how you look at it though, this shouldn't be a valid forum post in 2024...