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?