www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - s/TypeTuple/AliasSeq/g?

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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
Oct 20 2015
parent reply Dragos Carp <dragoscarp gmail.com> writes:
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
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Oct 20 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Oct 20 2015
prev sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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
Oct 20 2015
next sibling parent anonymous <anonymous example.com> writes:
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
prev sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
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.
Oct 21 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Oct 21 2015
parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
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.
Oct 21 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
parent Suliman <evermind live.ru> writes:
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
prev sibling next sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
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
Oct 21 2015
parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Wednesday, 21 October 2015 at 14:25:18 UTC, Shriramana Sharma 
wrote:
 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.
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.
 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,
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).
 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
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz 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.
It isn't. Not a single bit more than any other AliasSeq at least.
Oct 21 2015
parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
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:
 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.
It isn't. Not a single bit more than any other AliasSeq at least.
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")`?
Oct 21 2015
parent Dicebot <public dicebot.lv> writes:
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