Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replace all occurrences of TypeTuple in std.traits by AliasSeq?

-- 
Shriramana Sharma, Penguin #395953

On Tuesday, 20 October 2015 at 13:18:39 UTC, Shriramana Sharma wrote:
> Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replace all occurrences of TypeTuple in std.traits by AliasSeq?

Unfortunately it is not so easy. I think that we can proceed to replace `TypeTuple` in `std.traits`, only after we have `AliasSeq`-like names for non-private names like `BaseTypeTuple`, `RepresentationTypeTuple`, `TransitiveBaseTypeTuple` or even `isTypeTuple`. IMO they belong together.

On Tuesday, 20 October 2015 at 14:10:01 UTC, Dragos Carp wrote:
> On Tuesday, 20 October 2015 at 13:18:39 UTC, Shriramana Sharma wrote:
>> Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replace all occurrences of TypeTuple in std.traits by AliasSeq?
>
> Unfortunately it is not so easy. I think that we can proceed to replace `TypeTuple` in `std.traits`, only after we have `AliasSeq`-like names for non-private names like `BaseTypeTuple`, `RepresentationTypeTuple`, `TransitiveBaseTypeTuple` or even `isTypeTuple`. IMO they belong together.

We should weed these out over time. Not really remove them, as to not break old code, but just create new names for these and remove old name from the doc and all.

On Tuesday, 20 October 2015 at 18:09:31 UTC, deadalnix wrote:
> On Tuesday, 20 October 2015 at 14:10:01 UTC, Dragos Carp wrote:
>> On Tuesday, 20 October 2015 at 13:18:39 UTC, Shriramana Sharma wrote:
>>> Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replace all occurrences of TypeTuple in std.traits by AliasSeq?
>>
>> Unfortunately it is not so easy. I think that we can proceed to replace `TypeTuple` in `std.traits`, only after we have `AliasSeq`-like names for non-private names like `BaseTypeTuple`, `RepresentationTypeTuple`, `TransitiveBaseTypeTuple` or even `isTypeTuple`. IMO they belong together.
>
> We should weed these out over time. Not really remove them, as to not break old code, but just create new names for these and remove old name from the doc and all.

We should probably deprecate TypeTuple and any other public symbol with TypeTuple in its name, but those get used enough that I'd wait for AliasSeq to be out for at least a release or two before doing that. Otherwise, it would just create too many deprecation messages for many folks given how heavily TypeTuple is used. But if we don't deprecate it eventually, we'll probably have to keep explaining both TypeTuple and AliasSeq rather than just AliasSeq, because the uses of TypeTuple won't necessarily go away if we don't deprecate it.

- Jonathan M Davis

deadalnix wrote:

> We should weed these out over time. Not really remove them, as to not break old code, but just create new names for these and remove old name from the doc and all.

Working on this right now...

BTW "isExpressions" – what kind of singular/plural grammar is that? When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.

Also, though `AliasSeq` is the same as `TypeTuple`, it would seem `isTypeTuple` is not the same as what an `isAliasSeq` would be, since `isTypeTuple` seems to test for an `AliasSeq` containing only types and no expressions. Possibly this inconsistency is one of the reasons for the name change?

Anyhow, given that we are removing all references to "tuple", I would think "isTypeSeq" would be the appropriate parallel renaming of `isTypeTuple` to "isExpressionSeq".

But should there then be a separate `isAliasSeq`? I'm not sure how to do that. Code is appreciated...

-- 
Shriramana Sharma, Penguin #395953

On Wednesday, October 21, 2015 06:49 AM, Shriramana Sharma wrote:

> BTW "isExpressions" – what kind of singular/plural grammar is that? When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.

Makes sense to me. However, the similar name "isExpressionTuple" has apparently been dropped in favor of "isExpressions" in the past. Maybe dig up the discussion on that.

> Also, though `AliasSeq` is the same as `TypeTuple`, it would seem `isTypeTuple` is not the same as what an `isAliasSeq` would be, since `isTypeTuple` seems to test for an `AliasSeq` containing only types and no expressions. Possibly this inconsistency is one of the reasons for the name change?

Yup.

> Anyhow, given that we are removing all references to "tuple", I would think "isTypeSeq" would be the appropriate parallel renaming of `isTypeTuple` to "isExpressionSeq".

If "isExpressionSeq" gets through, yes. If "isExpressions" stays, then "isTypes"? :/

> But should there then be a separate `isAliasSeq`? I'm not sure how to do that. Code is appreciated...

I don't think an isAliasSeq template makes sense. Every set of template arguments is an AliasSeq, so isAliasSeq would just always return true. There's no point in that.

On Wednesday, 21 October 2015 at 04:49:14 UTC, Shriramana Sharma wrote:
> deadalnix wrote:
>
>> We should weed these out over time. Not really remove them, as to not break old code, but just create new names for these and remove old name from the doc and all.
>
> Working on this right now...
>
> BTW "isExpressions" – what kind of singular/plural grammar is that?

That's because it refers to the first argument, which is one symbol, not multiple ones. "consistsOfExpression" would probably be nicer, but - meh...

> When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.

This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.

>
> Also, though `AliasSeq` is the same as `TypeTuple`, it would seem `isTypeTuple` is not the same as what an `isAliasSeq` would be, since `isTypeTuple` seems to test for an `AliasSeq` containing only types and no expressions. Possibly this inconsistency is one of the reasons for the name change?
>
> Anyhow, given that we are removing all references to "tuple",

We aren't. The only reason we use "AliasSeq" at all instead of "AliasTuple" was that some people insisted they were not tuples. This does however not apply to all the other things that _are_ tuples. Renaming those would only make matters worse.

On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:
> On Wednesday, 21 October 2015 at 04:49:14 UTC, Shriramana Sharma wrote:
>> When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.
>
> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.

Except that it still isn't a tuple even if it only contains expressions.

> We aren't. The only reason we use "AliasSeq" at all instead of "AliasTuple" was that some people insisted they were not tuples. This does however not apply to all the other things that _are_ tuples. Renaming those would only make matters worse.

_Nothing_ which is an AliasSeq is a tuple. What it contains is irrelevant. The simple fact is that they auto-flatten and are not composable like tuples are. Calling them tuples has consistently created confusion.

- Jonathan M Davis

Marc Schütz wrote:

>> BTW "isExpressions" – what kind of singular/plural grammar is that?
> 
> That's because it refers to the first argument, which is one symbol, not multiple ones. "consistsOfExpression" would probably be nicer, but - meh...

No it doesn't refer to the first argument. The code in Phobos is:

    static if (T.length >= 2)
        enum bool isExpressions =
            isExpressions!(T[0 .. $/2]) &&
            isExpressions!(T[$/2 .. $]);
    else static if (T.length == 1)
        enum bool isExpressions =
            !is(T[0]) && __traits(compiles, { auto ex = T[0]; });
    else
        enum bool isExpressions = true; // default

So it does check all members of the AliasSeq, and only if all of them are expressions (or at least none of them are types) then it returns true. The counterpart is isTypeTuple.

> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.
> 
> ...
> We aren't. The only reason we use "AliasSeq" at all instead of
> "AliasTuple" was that some people insisted they were not tuples.
> This does however not apply to all the other things that _are_
> tuples. Renaming those would only make matters worse.

Heh, I guess you were one of the dissenters during the rename from TypeTuple to AliasSeq. I personally don't have a problem with calling them tuples, and IIUC the main problem was with the word Type since they can contain even expressions, but nevertheless it *was* renamed to AliasSeq, and if the library is to have any consistency and professional quality then the rest of the references to "Tuple" (and even some internal "List" references) as against tuples created by `std.typecons.Tuple` should be corrected.

-- 
Shriramana Sharma, Penguin #395953

On Wednesday, 21 October 2015 at 14:11:21 UTC, Jonathan M Davis wrote:
> On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:
>> On Wednesday, 21 October 2015 at 04:49:14 UTC, Shriramana Sharma wrote:
>>> When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.
>>
>> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.
>
> Except that it still isn't a tuple even if it only contains expressions.
>
>> We aren't. The only reason we use "AliasSeq" at all instead of "AliasTuple" was that some people insisted they were not tuples. This does however not apply to all the other things that _are_ tuples. Renaming those would only make matters worse.
>
> _Nothing_ which is an AliasSeq is a tuple. What it contains is irrelevant. The simple fact is that they auto-flatten and are not composable like tuples are. Calling them tuples has consistently created confusion.

I won't repeat the objections against your arguments, as it leads to nothing. But this discussion again shows that the renaming of TypeTuple to AliasSeq was just done for the sake of it (as further witnessed by the way it was done). We shouldn't do more of that nonsense as long as there is no consistent concept and goal behind it.