From the Feedback Thread:

> * Major bug: the "Rationale" discusses only expression, whereas
> staticMap does not use expressions. It just processes tuples, which may
> contain types. Types cannot appear in expressions. C++ goes to great
> lengths to distinguish between template parameter packs (which may be
> one of type parameter pack, value parameter pack, and template template
> parameter pack) and function parameter packs (which may only be
> parameter declarations). By the Rationale nothing except expressions
> will be accessible to D's proposed "...". That means no staticMap for
> non-valies (e.g. staticMap!(Unqual, types)), which probably wasn't the
> intent of the DIP.

I am confused by this. Isn't it fine to work with expressions only?

I mean staticMap's implementation can be replaced with a ... expansion, because even though there might be types in the list, there are no types in staticMap, just tuples.

And a type can appear in an expression, as a template parameter:

alias everyOther = AliasSeq!(0, 2, 4);

alias everyOtherType = (AliasSeq!(int, uint, char, byte, ubyte, int)[everyOther])...;

I think the DIP is intending for staticMap to be wholesale replaced with this, and seems to be saying this to me. I don't understand the above complaint, and why static map wouldn't work with types.

Perhaps it's simply vocabulary that is the problem?

-Steve

On 10/29/20 9:48 AM, Steven Schveighoffer wrote:
>  From the Feedback Thread:
> 
>> * Major bug: the "Rationale" discusses only expression, whereas
>> staticMap does not use expressions. It just processes tuples, which may
>> contain types. Types cannot appear in expressions. C++ goes to great
>> lengths to distinguish between template parameter packs (which may be
>> one of type parameter pack, value parameter pack, and template template
>> parameter pack) and function parameter packs (which may only be
>> parameter declarations). By the Rationale nothing except expressions
>> will be accessible to D's proposed "...". That means no staticMap for
>> non-valies (e.g. staticMap!(Unqual, types)), which probably wasn't the
>> intent of the DIP.
> 
> I am confused by this. Isn't it fine to work with expressions only?
> 
> I mean staticMap's implementation can be replaced with a ... expansion, because even though there might be types in the list, there are no types in staticMap, just tuples.

I don't think it works that way, no.

> And a type can appear in an expression, as a template parameter:
> 
> alias everyOther = AliasSeq!(0, 2, 4);
> 
> alias everyOtherType = (AliasSeq!(int, uint, char, byte, ubyte, int)[everyOther])...;
> 
> I think the DIP is intending for staticMap to be wholesale replaced with this, and seems to be saying this to me. I don't understand the above complaint, and why static map wouldn't work with types.

What would the implementation of staticMap with the DIP look like? As far as I can tell from the DIP it cannot be done.

> Perhaps it's simply vocabulary that is the problem?

May as well. The way the DIP is written, there's no discussion of tuples containing anything else but values.

On 10/30/20 2:29 PM, Andrei Alexandrescu wrote:
> On 10/29/20 9:48 AM, Steven Schveighoffer wrote:
>> And a type can appear in an expression, as a template parameter:
>>
>> alias everyOther = AliasSeq!(0, 2, 4);
>>
>> alias everyOtherType = (AliasSeq!(int, uint, char, byte, ubyte, int)[everyOther])...;
>>
>> I think the DIP is intending for staticMap to be wholesale replaced with this, and seems to be saying this to me. I don't understand the above complaint, and why static map wouldn't work with types.
> 
> What would the implementation of staticMap with the DIP look like? As far as I can tell from the DIP it cannot be done.

It has the implementation right in the DIP:

alias staticMap(alias F, T...) = F!T...;

>> Perhaps it's simply vocabulary that is the problem?
> 
> May as well. The way the DIP is written, there's no discussion of tuples containing anything else but values.

In the examples there are. e.g.:

alias Values = AliasSeq!(1, 2, 3);
alias Types = AliasSeq!(int, short, float);
pragma(msg, cast(Types)Values...);

> cast(int)1, cast(short)2, cast(float)3

Maybe it's not as clear with terminology. In some places it talks about tuples and their "elements", and in others, it talks about "values". I don't think it ever specifically talks about types in the description.

-Steve

On Sat, Oct 31, 2020 at 9:10 AM Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 10/30/20 2:29 PM, Andrei Alexandrescu wrote:
> > On 10/29/20 9:48 AM, Steven Schveighoffer wrote:
> >> And a type can appear in an expression, as a template parameter:
> >>
> >> alias everyOther = AliasSeq!(0, 2, 4);
> >>
> >> alias everyOtherType = (AliasSeq!(int, uint, char, byte, ubyte,
> >> int)[everyOther])...;
> >>
> >> I think the DIP is intending for staticMap to be wholesale replaced with this, and seems to be saying this to me. I don't understand the above complaint, and why static map wouldn't work with types.
> >
> > What would the implementation of staticMap with the DIP look like? As far as I can tell from the DIP it cannot be done.
>
> It has the implementation right in the DIP:
>
> alias staticMap(alias F, T...) = F!T...;
>
> >> Perhaps it's simply vocabulary that is the problem?
> >
> > May as well. The way the DIP is written, there's no discussion of tuples containing anything else but values.
>
> In the examples there are. e.g.:
>
> alias Values = AliasSeq!(1, 2, 3);
> alias Types = AliasSeq!(int, short, float);
> pragma(msg, cast(Types)Values...);
>
>  > cast(int)1, cast(short)2, cast(float)3
>
> Maybe it's not as clear with terminology. In some places it talks about tuples and their "elements", and in others, it talks about "values". I don't think it ever specifically talks about types in the description.
>
> -Steve
>

I was about to raise both those examples you showed here. I show
staticMap's implementation right there, and I also show types in tuples.
The trouble as I see is that there's a spec language problem, where a tuple
element is a 'kind of thing' that I don't know what to call that.
It may be a value, or a type, or an alias, and in most cases, I don't refer
to the contents of the tuple, just to the tuple itself. The kind of thing
in the elements is largely irrelevant to this dip; it's a later phase in
compilation where (as with any tuple in normal circumstances) the elements
of the tuple are determined to have some meaning in context.

I think people are hung up by my use of the word 'expression' to mean "some
syntax tree" involving whatever kind of thing that may be in the tuple
elements...?
What do you call this: MyTypeTuple[10]  ?
Is that an index *expression*? Internally, it's an IndexExp, but the tuple
does not have expression elements, so the result is not an expression, it's
a type. I would call that an expression as applied to a tuple regardless
what kind of thing the result is.
What about this: MyThing.Member  <- where Member may be a type. Internally
that's called a DotIdExp... so it's still an expression, even if it's
result is not an expression.

Can you show where my use of language in this DIP is inconsistent with these precedents?

On 10/30/20 7:55 PM, Manu wrote:
> I was about to raise both those examples you showed here. I show staticMap's implementation right there, and I also show types in tuples.
> The trouble as I see is that there's a spec language problem, where a tuple element is a 'kind of thing' that I don't know what to call that.

Sorry, I must have missed it!

I think a good term is "alias sequence" because AliasSeq in std.meta comprises exactly those. Generally relating this to stuff and terms in the language spec and stdlib docs would be great.

On Friday, 30 October 2020 at 23:55:54 UTC, Manu wrote:
>
> I was about to raise both those examples you showed here. I show
> staticMap's implementation right there, and I also show types in tuples.
> The trouble as I see is that there's a spec language problem, where a tuple
> element is a 'kind of thing' that I don't know what to call that.

I think "tuple element" is probably the best you can do. It's a little clunky, but clunky is better than ambiguous.

> What do you call this: MyTypeTuple[10]  ?
> Is that an index *expression*? Internally, it's an IndexExp, but the tuple
> does not have expression elements, so the result is not an expression, it's
> a type. I would call that an expression as applied to a tuple regardless
> what kind of thing the result is.
> What about this: MyThing.Member  <- where Member may be a type. Internally
> that's called a DotIdExp... so it's still an expression, even if it's
> result is not an expression.

According to the grammar in the language spec, these are both IdentifierLists [1] when they appear in a context where a type is expected. In a context where an expression is expected, `MyTuple[10]` is an IndexExpression [2], and `MyThing.Member` is a PostfixExpression [3]. There is no such thing as a DotIdExp in the language spec.

In general, if you need to refer to a particular syntactic construct, I think it's better to use the name from the language spec, rather than the DMD-internal class name.

[1] https://dlang.org/spec/grammar.html#IdentifierList
[2] https://dlang.org/spec/grammar.html#IndexExpression
[3] https://dlang.org/spec/grammar.html#PostfixExpression

On Saturday, 31 October 2020 at 01:47:37 UTC, Andrei Alexandrescu wrote:
> On 10/30/20 7:55 PM, Manu wrote:
>> I was about to raise both those examples you showed here. I show staticMap's implementation right there, and I also show types in tuples.
>> The trouble as I see is that there's a spec language problem, where a tuple element is a 'kind of thing' that I don't know what to call that.
>
> Sorry, I must have missed it!
>
> I think a good term is "alias sequence" because AliasSeq in std.meta comprises exactly those. Generally relating this to stuff and terms in the language spec and stdlib docs would be great.

You should call it a template parameter list.

On Saturday, 31 October 2020 at 06:59:11 UTC, Stefan Koch wrote:
> You should call it a template parameter list.

It doesn't necessarily go to a template. I think the same class in dmd handles both though since you can pass values to a template too, just perhaps worth noting it is supposed to accept things that would cause a semantic error if passed to an actual template.

On Sat, Oct 31, 2020 at 11:50 AM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 10/30/20 7:55 PM, Manu wrote:
> > I was about to raise both those examples you showed here. I show staticMap's implementation right there, and I also show types in tuples. The trouble as I see is that there's a spec language problem, where a tuple element is a 'kind of thing' that I don't know what to call that.
>
> Sorry, I must have missed it!
>
> I think a good term is "alias sequence" because AliasSeq in std.meta comprises exactly those. Generally relating this to stuff and terms in the language spec and stdlib docs would be great.
>

So should I drop the language 'tuple' entirely? D doesn't actually propose to have tuples, I guess that's just the colloquial name for alias sequences.

On Sat, Oct 31, 2020 at 12:05 PM Paul Backus via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 30 October 2020 at 23:55:54 UTC, Manu wrote:
> >
> > I was about to raise both those examples you showed here. I show
> > staticMap's implementation right there, and I also show types
> > in tuples.
> > The trouble as I see is that there's a spec language problem,
> > where a tuple
> > element is a 'kind of thing' that I don't know what to call
> > that.
>
> I think "tuple element" is probably the best you can do. It's a little clunky, but clunky is better than ambiguous.
>

If I drop the term "tuple" for "alias sequence", then that results in "alias sequence element", which really doesn't roll off the tongue!

> What do you call this: MyTypeTuple[10]  ?
> > Is that an index *expression*? Internally, it's an IndexExp,
> > but the tuple
> > does not have expression elements, so the result is not an
> > expression, it's
> > a type. I would call that an expression as applied to a tuple
> > regardless
> > what kind of thing the result is.
> > What about this: MyThing.Member  <- where Member may be a type.
> > Internally
> > that's called a DotIdExp... so it's still an expression, even
> > if it's
> > result is not an expression.
>
> According to the grammar in the language spec, these are both IdentifierLists [1] when they appear in a context where a type is expected. In a context where an expression is expected, `MyTuple[10]` is an IndexExpression [2], and `MyThing.Member` is a PostfixExpression [3]. There is no such thing as a DotIdExp in the language spec.
>
> In general, if you need to refer to a particular syntactic construct, I think it's better to use the name from the language spec, rather than the DMD-internal class name.
>
> [1] https://dlang.org/spec/grammar.html#IdentifierList
> [2] https://dlang.org/spec/grammar.html#IndexExpression
> [3] https://dlang.org/spec/grammar.html#PostfixExpression


Is "Alias Sequence" present in spec language?
This really demonstrates how much D needs first-class tuples; this area of
the language is a shit-fight, and essentially just a weird abuse of
template argument lists mixed with `alias` and some implementation defined
behaviour, which happens to look and feel a lot like a tuple.