On 2015-07-15 18:09, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:

> Yeah, "splat" as a name for an auto-expanding thingy would be a novelty.
> Ruby for instance doesn't have anything like that, it has a splat
> _operator_ (asterisk) to expand a normal array, or conversely, capture
> several arguments in one parameter.

I'm not sure what should count as auto-expanding, but this works in Ruby:

a, b = [1, 2]

No extra operator is required in this case.

-- 
/Jacob Carlborg

On Wednesday, 15 July 2015 at 18:21:10 UTC, Andrei Alexandrescu wrote:
> On 7/15/15 11:54 AM, Deadalnix wrote:
>> That how I ended up with seq in the first place. I went to talk to
>> everybody and sequence was what came up the most while not having people
>> as opposed to it as list.
>
> Now I'm sorry I even started. I'd be happy to return to AliasSeq. -- Andrei

Luckily we have 2 people that can just decide.
I reckon at this stage yourself and Walter should just pick the name ye prefer best and go with it.

The democratic approach, I feel anyway, hasn't worked in this case... (Doesn't mean it wont in future!!)

On 07/15/2015 05:35 PM, Dicebot wrote:
> On Wednesday, 15 July 2015 at 15:29:25 UTC, Andrei Alexandrescu wrote:
>>> It doesn't confuse me. We have type tuples and expression tuples defined
>>> in the spec. An alias tuple can have both expressions and types. It's
>>> not that confusing. What was confusing is that a TypeTuple was not a
>>> type tuple as defined in the spec.
>>
>> I agree.
>>
>> Andrei
>
> I want to point out that statement "an alias tuple can have both
> expressions and types" is somewhat between imprecise and just wrong with
> current compiler implementation. `X!(42, int, foo)` doesn't hold aliases
> to value, type and symbol (assuming X(T...)) - it does hold actual value
> and type, with only symbol being aliased. Actual alias tuple would be
> defined as `X(alias a, alias b, alias c)` and is somewhat different thing.
>
> You may want to ignore that difference for simplicity sake but it needs
> to be explicitly acknowledged.

It should instead be acknowledged that there /should/ be no difference in what three things can be passed to X(T...) and X(alias a, alias b, alias c). The X(T...) if(T.length==k) pattern is ridiculous.

On 07/15/2015 08:21 PM, Andrei Alexandrescu wrote:
> On 7/15/15 11:54 AM, Deadalnix wrote:
>> That how I ended up with seq in the first place. I went to talk to
>> everybody and sequence was what came up the most while not having people
>> as opposed to it as list.
>
> Now I'm sorry I even started. I'd be happy to return to AliasSeq. -- Andrei

+1.

On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:
>
> What happened? Why are we replacing a crappy term with another crappy term?
>

Here's my interpretation of the current state of this as I read this thread
1. "AliasSeq" is no good as evident from the first post that started this thread
2. "AliasList" draws veto from decision makers due to list semantics in C++
3. "AliasTuple" draws both support and disdain, but at least there's some support.  Also, I volunteered to wordsmith the documentation on this, and I found myself a little dumbstruck yesterday trying to explain it.
4. "AliasSplat" uses a frivolous and slang term for the asterisk operator so is hard to take seriously, and like the other suggestions will require explanation.
5. "Arguments" isn't bad IMO, but it seems to draw disdain due to the fact that the construct in question may or may not be used for template arguments.

So, my asbestos underwear is on, and I ask if there is any support for the "CompileTimeEntityList".  I know it contains the 'L'-word, so if you prefer consider "CompileTimeEntities".  If the length bothers you, then consider "CTEList" (could also be interpreted as Compile-time element list, I suppose).

I have one other suggestion, but I'd like to see how this goes first.  Given the current state of things, it appears that remaining silent or voicing disapproval without a viable suggestion is an implicit vote for "AliasTuple".

Mike

On 07/16/2015 02:49 AM, Mike wrote:
> On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:
>>
>> What happened? Why are we replacing a crappy term with another crappy
>> term?
>>
>
> Here's my interpretation of the current state of this as I read this thread
> 1. "AliasSeq" is no good as evident from the first post that started
> this thread

Not at all evident. The only argument given in that post was not particularly valid.

On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:

> So, my asbestos underwear is on, and I ask if there is any support for the "CompileTimeEntityList".  I know it contains the 'L'-word, so if you prefer consider "CompileTimeEntities".  If the length bothers you, then consider "CTEList" (could also be interpreted as Compile-time element list, I suppose).
>

I suppose "CompileTimeTuple" or "CTTuple" would be fine too, especially if we prefer to think of tuples as heterogeneous lists.

On Thu, Jul 16, 2015 at 04:05:17AM +0000, Mike via Digitalmars-d wrote:
> On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:
> 
> >So, my asbestos underwear is on, and I ask if there is any support for the "CompileTimeEntityList".  I know it contains the 'L'-word, so if you prefer consider "CompileTimeEntities".  If the length bothers you, then consider "CTEList" (could also be interpreted as Compile-time element list, I suppose).
> >
> 
> I suppose "CompileTimeTuple" or "CTTuple" would be fine too, especially if we prefer to think of tuples as heterogeneous lists.

"Tuple" was the original term used for this, and was also the term that started the whole debate because people thought it implied something that didn't fit in with how these things actually worked. It did not help that Phobos also defines a "Tuple" type, with more "traditional" tuple behaviour, that's based on this "TypeTuple" but different. However, the names being so similar, people were confusing and conflating the two, which led to all kinds of misunderstandings and confusion.

If we're going to use any name with "Tuple" at all, we might as well just admit defeat and go back to the original "TypeTuple" after all, since nothing else seems to be any better.

I think any successful name is going to have to be outside the usual suspects -- tuple, sequence, list, array, etc.. All of them have connotations that don't apply to this thing, and all of them lead the unwary to assume things about it that may not be correct. In fact, "sequence" so far is probably the least evil of all the alternatives, if only it weren't so long to spell out. I'm quite happy with AliasSeq, to be honest, though some people hate gratuitous abbreviations. I think it should just stay as AliasSeq, per Andrei's recent response.

But in any case, if people think AliasSeq is not good enough, then we really have to think outside the box, because none of the usual candidates are going to work. AliasBeads (that I jokingly suggested), or AliasBraids, or ... various other silly names that kinda prove the point that we'd better just stick with AliasSeq and call it a day, instead of spending yet more time and energy on this long-dead horse.


T

-- 
That's not a bug; that's a feature!

On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:
> On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:
>>
>> What happened? Why are we replacing a crappy term with another crappy term?
>>
>
> Here's my interpretation of the current state of this as I read this thread
> 1. "AliasSeq" is no good as evident from the first post that started this thread
> 2. "AliasList" draws veto from decision makers due to list semantics in C++
> 3. "AliasTuple" draws both support and disdain, but at least there's some support.  Also, I volunteered to wordsmith the documentation on this, and I found myself a little dumbstruck yesterday trying to explain it.
> 4. "AliasSplat" uses a frivolous and slang term for the asterisk operator so is hard to take seriously, and like the other suggestions will require explanation.
> 5. "Arguments" isn't bad IMO, but it seems to draw disdain due to the fact that the construct in question may or may not be used for template arguments.

You forgot "Aliases", which also was suggested.

On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:
> 2. "AliasList" draws veto from decision makers due to list semantics in C++

Actually, "AliasList" is the most accurate term. "List" does not imply linked list in C++ or any other language I know of. C++ uses the term "list" for arguments. E.g:

va_list
std::forward_list
std::initializer_list

http://en.cppreference.com/mwiki/index.php?title=Special%3ASearch&search=list

(But keep it going, this thread is entertaining…)