On Sat, May 9, 2020 at 7:20 AM Adam D. Ruppe via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 8 May 2020 at 20:53:39 UTC, Q. Schroll wrote:
> >     alias Tup = Tuple!(int, long);
>
> This is just a struct, the ... shouldn't do anything to it
> (probably should be a syntax error).
>
> The ... thing is all about compiler tuples which are unfortunately named the same but totally separate to library tuples.
>

^^^
std.typecons.Tuple is a struct. It's not a tuple.

On Sat, May 9, 2020 at 3:15 AM Q. Schroll via Digitalmars-d < digitalmars-d@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@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.

On 24.04.20 23:00, Steven Schveighoffer wrote:
> On 4/24/20 4:15 PM, Walter Bright wrote:
> 
>>
>> Since then it's an array, use the existing array folding methods.
> 
> This is probably good enough, because we can generate arrays at compile-time and process them via CTFE.
> 
> Some key targets within std.meta are anySatisfy/allSatisfy.
> 
> A quick stab at this (I'm going to stick with the ellipsis version as it's easy to ):
> 
> import std.algorithm : canFind;
> enum anySatisfy(alias F, T...) = [F!(T)...].canFind(true);
> enum allSatisfy(alias F, T...) = ![F!(T)...].canFind(false);
> 
> Wow, that reads so clean.
> 
> I'm so in love with this feature, when can we get it in?
> 
> -Steve

This is not equivalent to the current implementations.

import std.meta;

enum Foo(int x)=true;
// true now, but compile error with your approach:
pragma(msg, anySatisfy!(Foo, 1, int));

On 24.04.20 10:03, Walter Bright wrote:
> On 4/24/2020 12:10 AM, Manu wrote:
>> Your idea all falls over anywhere it encounters variadic args, or potential for overloads though. Without an explicit expression, the only way forward is to preserve existing D semantics (or it's a radically breaking change), and that will severely narrow the applicability of this proposal.
>>
>> Consider this:
>>
>>    alias Tup = AliasSeq!(0, 2, 3);
>>    void fun(int);
>>    fun(Tup);  // scalar argument receives tuple, it can expand, so: fun(0), fun(1), fun(2)
> 
> Write it as:
> 
>      Tup.fun();
> ...

That's the same thing.

import std.stdio, std.meta;
alias seq = AliasSeq!(0, 2, 3);

void fun(int a, int b, int c){
    writeln(a," ",b," ",c);
}

void main(){
    seq.fun(); // 0 2 3
}

Hijacking UFCS to designate some independent distinction is bad language design. Language features should be orthogonal.

> Of course,
> 
>      fun(1, Tup);
> 
> cannot be rewritten in this way, but then a rationale will be necessary as to why it must be written as func(1, Tup) instead of fun(Tup, 1).

Certainly not. The order of parameters of func is what it is and depending on the situation you will want to expand one or the other.

On 25.04.20 00:21, Walter Bright wrote:
> On 4/24/2020 1:55 PM, Walter Bright wrote:
>> How are things like this expressed in mathematics?
> 
> I did a little research:
> 
>      ∀xP(x)
> 
> means:
> 
>      for all x in P(x)
> 
> or in ... notation:
> 
>      P(x...)

Actually, ∀x. P(x) is closer to the meaning of P(x) && ... with Manu's notation.

P(x)... could be something like:

expand x in P(x).

On 25.04.20 02:57, Steven Schveighoffer wrote:
> untypeable symbols

Pet peeve. There's no such thing. Just configure your computer so you can type them.

On 10/05/2020 3:46 AM, Timon Gehr wrote:
> On 25.04.20 02:57, Steven Schveighoffer wrote:
>> untypeable symbols
> 
> Pet peeve. There's no such thing. Just configure your computer so you can type them.

ų = ⎄ , u

Compose ♥, I mean anything is type-able if you care enough.

On 25.04.20 23:21, Walter Bright wrote:
> On 4/25/2020 4:25 AM, Manu wrote:
>> It's still un-fun to type AliasSeq!(), and I've never liked how it reads or looks... but your patch is certainly welcome.
> 
> It was originally TypeTuple!(), and still is in druntime. (Yes, the PR recognizes TypeTuple, too, as it recognizes the pattern, not the identifier.) I don't know why it was changed to AliasSeq, which just grates on me as not indicating at all what it is. Probably Tuple would be the best name.

Tuple does not indicate at all what it is. Tuples usually don't auto-expand.

On 09.05.20 02:21, Manu wrote:
> On Sat, May 9, 2020 at 7:20 AM Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
> 
>     On Friday, 8 May 2020 at 20:53:39 UTC, Q. Schroll wrote:
>      >     alias Tup = Tuple!(int, long);
> 
>     This is just a struct, the ... shouldn't do anything to it
>     (probably should be a syntax error).
> 
>     The ... thing is all about compiler tuples which are
>     unfortunately named the same but totally separate to library
>     tuples.
> 
> 
> ^^^
> std.typecons.Tuple is a struct. It's not a tuple.

It implements a tuple. It's just not a weird built-in compiler "tuple".

On 5/9/20 11:28 AM, Timon Gehr wrote:
> On 24.04.20 23:00, Steven Schveighoffer wrote:
>> On 4/24/20 4:15 PM, Walter Bright wrote:
>>
>>>
>>> Since then it's an array, use the existing array folding methods.
>>
>> This is probably good enough, because we can generate arrays at compile-time and process them via CTFE.
>>
>> Some key targets within std.meta are anySatisfy/allSatisfy.
>>
>> A quick stab at this (I'm going to stick with the ellipsis version as it's easy to ):
>>
>> import std.algorithm : canFind;
>> enum anySatisfy(alias F, T...) = [F!(T)...].canFind(true);
>> enum allSatisfy(alias F, T...) = ![F!(T)...].canFind(false);
>>
>> Wow, that reads so clean.
>>
>> I'm so in love with this feature, when can we get it in?
>>
> 
> This is not equivalent to the current implementations.
> 
> import std.meta;
> 
> enum Foo(int x)=true;
> // true now, but compile error with your approach:
> pragma(msg, anySatisfy!(Foo, 1, int));

I'm not sure I'd call that a "feature" though, or just invalid input:

pragma(msg, anySatisfy!(Foo, int, 1)) => error.

This should provide the best situation I think:

template evalBool(alias F, V...) if (V.length == 1){
    static if(is(typeof(F!V) == bool))
      enum evalBool = F!V;
    else
      enum evalBool = false;
}

enum anySatisfy(alias F, T...) = [evalBool!(F, T)...].canFind(true);

-Steve