digitalmars.D - s/TypeTuple/AliasSeq/g?
- Shriramana Sharma (4/4) Oct 20 2015 Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replac...
- Dragos Carp (7/10) Oct 20 2015 Unfortunately it is not so easy. I think that we can proceed to
- deadalnix (4/15) Oct 20 2015 We should weed these out over time. Not really remove them, as to
- Jonathan M Davis (11/27) Oct 20 2015 We should probably deprecate TypeTuple and any other public
- Shriramana Sharma (18/21) Oct 20 2015 Working on this right now...
- anonymous (10/24) Oct 20 2015 Makes sense to me. However, the similar name "isExpressionTuple" has
- Marc =?UTF-8?B?U2Now7x0eg==?= (11/27) Oct 21 2015 That's because it refers to the first argument, which is one
- Jonathan M Davis (8/19) Oct 21 2015 Except that it still isn't a tuple even if it only contains
- Marc =?UTF-8?B?U2Now7x0eg==?= (8/29) Oct 21 2015 I won't repeat the objections against your arguments, as it leads
- Jonathan M Davis (13/19) Oct 21 2015 The renaming was done in an attempt to fix a particularly bad
- Suliman (3/9) Oct 27 2015 +1
- Shriramana Sharma (23/37) Oct 21 2015 No it doesn't refer to the first argument. The code in Phobos is:
- Marc =?UTF-8?B?U2Now7x0eg==?= (14/54) Oct 21 2015 I was referring to the "left hand side" of that relationship:
- Dicebot (2/7) Oct 21 2015 It isn't. Not a single bit more than any other AliasSeq at least.
- Marc =?UTF-8?B?U2Now7x0eg==?= (6/16) Oct 21 2015 For me, a tuple is a finite ordered collection of values of
- Dicebot (9/14) Oct 27 2015 For me important property is that tuple itself must be distinct
Since TypeTuple is now an alias of AliasSeq, I suppose it's OK to replace all occurrences of TypeTuple in std.traits by AliasSeq? --
Oct 20 2015
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.
Oct 20 2015
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: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.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.
Oct 20 2015
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: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 DavisOn Tuesday, 20 October 2015 at 13:18:39 UTC, Shriramana Sharma 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.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.
Oct 20 2015
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... --
Oct 20 2015
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.
Oct 20 2015
On Wednesday, 21 October 2015 at 04:49:14 UTC, Shriramana Sharma wrote:deadalnix wrote:That's because it refers to the first argument, which is one symbol, not multiple ones. "consistsOfExpression" would probably be nicer, but - meh...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.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.
Oct 21 2015
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:Except that it still isn't a tuple even if it only contains expressions.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.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
Oct 21 2015
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: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.On Wednesday, 21 October 2015 at 04:49:14 UTC, Shriramana Sharma wrote:Except that it still isn't a tuple even if it only contains expressions.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.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.
Oct 21 2015
On Wednesday, 21 October 2015 at 15:21:14 UTC, Marc Schütz wrote: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.The renaming was done in an attempt to fix a particularly bad name that has caused a lot of confusion. The result is another bad name that's likely to create confusion for different reasons. As to whether we're better or worse off, I don't know. Regardless, we're not normally renaming stuff like this anymore. It was just done in this case, because TypeTuple was almost universally reviled, and Walter and Andrei agreed that it was bad enough that it needed changing. So, issues like this aren't likely to be a common occurrence at this point. Still, it would have been nice if we could have come up with a name for TypeTuple/AliasSeq that was actually good... - Jonathan M Davis
Oct 21 2015
On Wednesday, 21 October 2015 at 15:25:34 UTC, Jonathan M Davis wrote:On Wednesday, 21 October 2015 at 15:21:14 UTC, Marc Schütz wrote: The renaming was done in an attempt to fix a particularly bad name that has caused a lot of confusion. The result is another bad name that's likely to create confusion for different reasons. As to whether we're better or worse off, I don't know.+1
Oct 27 2015
Marc Schütz wrote: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.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...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. --
Oct 21 2015
On Wednesday, 21 October 2015 at 14:25:18 UTC, Shriramana Sharma wrote:Marc Schütz wrote:I was referring to the "left hand side" of that relationship: "something" is-a "expressions" The "is" makes sense if you see it as an "is-a" relationship.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.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...That is my understanding as well. And the fact that they can contain anything, not just values, was another reason for some not to call them tuples (which I don't consider important, but it was for some).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.I'm afraid this won't help. One objection was that we're dealing with several different unrelated concepts that only superficially seem similar, and that all used to be called "tuple". Now, when we just mechanically rename them all to "*Seq", we're back where we started, just with a different name.
Oct 21 2015
On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:It isn't. Not a single bit more than any other AliasSeq at least.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.
Oct 21 2015
On Wednesday, 21 October 2015 at 16:00:57 UTC, Dicebot wrote:On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:For me, a tuple is a finite ordered collection of values of arbitrary type, which can be identified and accessed by their index. Which definition of tuple are you using that doesn't apply to e.g. `AliasSeq!(42, "foo")`?It isn't. Not a single bit more than any other AliasSeq at least.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.
Oct 21 2015
On Wednesday, 21 October 2015 at 16:17:46 UTC, Marc Schütz wrote:For me, a tuple is a finite ordered collection of values of arbitrary type, which can be identified and accessed by their index. Which definition of tuple are you using that doesn't apply to e.g. `AliasSeq!(42, "foo")`?For me important property is that tuple itself must be distinct entity that can be passed around and is generally full part of the type system. Also destructuring is one of established tuple features in other languages. Limiting it to values is irrelevant (but somewhat necessary to define ABI because of mentioned property). Obviosuly, I am referring to established programming "tuple" concept, not math term it originates from.
Oct 27 2015