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.

😫

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

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.
>
> 😫

I am going to fix this if it's not fixed by next week.
I feel like going back to this.

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

On Saturday, 24 August 2024 at 18:31:21 UTC, Stefan Koch 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.
>>
>> 😫
>
> I am going to fix this if it's not fixed by next week.
> I feel like going back to this.

The feature might be covered in this old PR (https://github.com/dlang/dmd/pull/11273/files). However it covered a wider scope.

On Sun, 25 Aug 2024 at 04:56, ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> 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...

Here's another one just now:

return __traits(getMember, instance, funName)(args);   // this works as it
should


alias fun = __traits(getMember, instance, funName);
return fun(args);   // error : calling non-static function `myFun` requires
an instance of type `T`


Again... this isn't acceptable in 2024. No 'explanation' should be acceptable to any sound mind. It's a critical bug, and it should have been fixed 15-20 years ago.

On Sun, 25 Aug 2024 at 15:07, Manu <turkeyman@gmail.com> wrote:

> On Sun, 25 Aug 2024 at 04:56, ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> 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...
>

On Sunday, 25 August 2024 at 06:59:11 UTC, Manu wrote:
> Here's another one just now:
>
> return __traits(getMember, instance, funName)(args);   // this works as it
> should
>
>
> alias fun = __traits(getMember, instance, funName);
> return fun(args);   // error : calling non-static function `myFun` requires
> an instance of type `T`

Funny error message. Where does myFun and T come from?

On Sun, 25 Aug 2024 at 19:11, Dom DiSc via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 25 August 2024 at 06:59:11 UTC, Manu wrote:
> > Here's another one just now:
> >
> > return __traits(getMember, instance, funName)(args);   // this
> > works as it
> > should
> >
> >
> > alias fun = __traits(getMember, instance, funName);
> > return fun(args);   // error : calling non-static function
> > `myFun` requires
> > an instance of type `T`
>
> Funny error message. Where does myFun and T come from?
>

struct T
{
  void myFun(int) {}
}
T instance;
enum funName = "myFun";

Related issue we've had in the recent year:

https://issues.dlang.org/show_bug.cgi?id=23500

https://issues.dlang.org/show_bug.cgi?id=23761

I thought it was resolved, but perhaps not.