Discussion Thread: DIP 1037--Add Unary Operator ...--Community Review Round 1

Manu turkeyman at gmail.com
Fri Oct 30 23:55:54 UTC 2020


On Sat, Oct 31, 2020 at 9:10 AM Steven Schveighoffer via Digitalmars-d <
digitalmars-d at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20201031/18b08131/attachment.htm>


More information about the Digitalmars-d mailing list