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

[Manu]

On Mon, Nov 2, 2020 at 8:15 AM Ola Fosheim Grøstad via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Sunday, 1 November 2020 at 21:47:26 UTC, Manu wrote:
> > Why? I don't agree with this at all. I actually expect tuples
> > DON'T have struct semantics.
>
> Well, it is a good thing if they behave as immutable structs as
> you then can get a more uniform language.
>

I think it is conceptually improper for a tuple to have a memory layout;
especially considering tuples can hold elements that are types or aliases
in addition to typed values.


> > The thing my DIP talks about are things that don't have struct
> > semantics...
> > what is that called?
>
> I was wrong, in a way, as structs can have aliases as fields (I
> believe phobos Tuple does this?). Although it would be better if
> it was more akin to typeid so that they had a counterpart at
> runtime (so that a regular function can return all tuples), but
> that would require a language change.
>
> But it would also make what Stephan try to do easier? His
> typefunctions would just be regular functions returning a
> type-identifer.
>

I think type functions are a great initiative, and I've talked with him
about that a lot.
I don't think this DIP competes with type functions. I also think type
functions will need a LOT of work to materialise.

> Make a DIP then. I don't like that idea. It's problematic to
> > know if you are dealing with a kind of thing that can be
> > unrolled until much later in semantic when it should have
> > already been done.
>
> The semantic passes can determine when the operator should be
> evaluated.
>

Under my DIP, the map is applied very early, pre-semantic. The resulting
tuple must compile in context and make semantic sense, and this is very
important such that it can be used in a wide variety of interesting
contexts.
It's also extremely complicated to know what the output of `...` applied to
an array-like thing should be? Is it a tuple? If you apply `...` to an
array or a range, and it becomes a tuple, that is probably going to reveal
serious semantic problems.

Imagine this:
  void fun(MyRange r) { ... }

  MyRange constantRange;
  fun(constantRange); // <-- function receives range as argument
  fun(expr(constantRange)...); // <-- the function call fails because the
range got turned into a tuple.


Or this:
  immutable int[] allTheThings = [ ... ];
  alias Selection = AliasSeq!(5, 1, 15);
  alias res = allTheThings[Selection]...; // <-- we have an array, and a
tuple both participating in the map; if `...` applied to array-like-things,
then this extremely important pattern would be impossible

If it attempts a parallel expansion as is specified in the DIP, then
immediately, the lengths do not match, but more importantly, the expression
doesn't even make functional sense anymore.
This DIP applies to tuples, specifically, and exclusively. You need to
design a completely different DIP if you think that's wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20201102/a3f6e423/attachment.htm>