I dun a DIP, possibly the best DIP ever

[Manu]

On Sat, May 9, 2020 at 3:15 AM Q. Schroll via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Wednesday, 22 April 2020 at 13:37:26 UTC, Manu wrote:
> > On Wed, Apr 22, 2020 at 11:35 PM rikki cattermole via
> > Digitalmars-d < digitalmars-d at puremagic.com> wrote:
> >
> >> On 23/04/2020 1:22 AM, Steven Schveighoffer wrote:
> >> > On 4/22/20 8:19 AM, rikki cattermole wrote:
> >> >> Change it to something like .unpackSequence instead of ...
> >> >> and I would be happy.
> >> >
> >> > unpackSequence is a valid identifier. That would be a
> >> > breaking change. Plus it would be less obvious. If anything
> >> > it would have to be unpackSequence!(expr).
> >> >
> >> > Plus there is precedence with C++ for using ...
> >> >
> >> > And it makes intuitive sense -- you define tuples with T...
> >> >
> >> > -Steve
> >>
> >> Yeah.
> >>
> >> But it also has precedence with type properties such as
> >> mangleof instead of the approach C took with sizeof and
> >> friends.
> >>
> >> Right now we use it in parameters, adding it to the argument
> >> side with a completely different meaning ugh.
>
> You can distinguish "Types... params" from "Type[] params..." by
> where the dots are.
> In contrast to C and C++, D has a very strong principle that
> everything after the parameter (or declared variable) is not part
> of the type. So in the latter case, the dots clearly don't belong
> to the type.
>
> > I feel it's a perfectly natural expansion of the existing
> > meaning. I'm 300% happy with the syntax personally, I will have
> > a tantrum if you take it away from me.
>
> The syntax is perfectly fine for me. Don't be distracted by a
> single opinion. The ... token currently can only be used in (both
> template and function) parameter declarations (and `is`
> expressions where they are kind of the same as template
> parameters). You're introducing it in an expression and/or
> type-expression context which seems to be fine, but very
> technically, it's not. There's one example where it clashes:
> Type-safe variable argument functions that omit their last
> parameter's name.
>
> One thing I want to mention: Let Ts be the type sequence int,
> long, double[]; then
>
>      void f(Ts[]...);
>
> becomes ambiguous. It could mean (by the new proposal)
>

Does it though?
I don't think function declarations accept an expression in the argument
list... they are declarations.

Otherwise you'd be able to specify a function like:
  void f(10 + 1, Enum.key, nullptr);

I don't think my DIP interacts with function declarations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200509/cc496593/attachment-0001.htm>