On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote:
> 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.

I am all for that but it needs to be explicitly acknowledged and implemented together with a rename.

On Thursday, 16 July 2015 at 06:33:00 UTC, Jacob Carlborg wrote:
> On 2015-07-15 23:44, Timon Gehr wrote:
>
>> 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.
>
> I completely agree.

Walter has agreed at DConf that this (i.e. alias not accepting basic types) should be fixed.

 — David

On Thursday, 16 July 2015 at 10:19:11 UTC, Dicebot wrote:
> I am all for that but it needs to be explicitly acknowledged and implemented together with a rename.

There is no renaming involved here, as the issue concerns the alias parameter language constructs. Or are you suggesting using another keyword than "alias"?

 – David

On Thursday, 16 July 2015 at 13:48:06 UTC, David Nadlinger wrote:
> On Thursday, 16 July 2015 at 10:19:11 UTC, Dicebot wrote:
>> I am all for that but it needs to be explicitly acknowledged and implemented together with a rename.
>
> There is no renaming involved here, as the issue concerns the alias parameter language constructs. Or are you suggesting using another keyword than "alias"?
>
>  – David

I mean that if name AliasSomething goes to 2.068, matching change to compiler argument lists must land in same release - and there must be a change log entry connecting and explaining those two.

On Thursday, 16 July 2015 at 14:38:09 UTC, Dicebot wrote:
> I mean that if name AliasSomething goes to 2.068, matching change to compiler argument lists must land in same release - and there must be a change log entry connecting and explaining those two.

I disagree with that. These aren't related at all. The change would affect alias params, not argument lists (which already accept "everything").

 — David

On Thursday, 16 July 2015 at 14:40:16 UTC, David Nadlinger wrote:
> On Thursday, 16 July 2015 at 14:38:09 UTC, Dicebot wrote:
>> I mean that if name AliasSomething goes to 2.068, matching change to compiler argument lists must land in same release - and there must be a change log entry connecting and explaining those two.
>
> I disagree with that. These aren't related at all. The change would affect alias params, not argument lists (which already accept "everything").
>
>  — David

We are arguing about a name for argument lists. For name 'AliasSomething' to not be a lie, `T...` must be be absolutely identical to `alias a, alias b, ...` which currently is not the case.

On Thursday, 16 July 2015 at 14:44:23 UTC, Dicebot wrote:
>
> We are arguing about a name for argument lists. For name 'AliasSomething' to not be a lie, `T...` must be be absolutely identical to `alias a, alias b, ...` which currently is not the case.

We could just document that the compiler contains a bug in the current alias implementation, but AliasSomething is named after the specification of how alias must work. Then the alias fix can go into version +1.

On Thursday, 16 July 2015 at 15:21:01 UTC, Daniel N wrote:
> On Thursday, 16 July 2015 at 14:44:23 UTC, Dicebot wrote:
>>
>> We are arguing about a name for argument lists. For name 'AliasSomething' to not be a lie, `T...` must be be absolutely identical to `alias a, alias b, ...` which currently is not the case.
>
> We could just document that the compiler contains a bug in the current alias implementation, but AliasSomething is named after the specification of how alias must work. Then the alias fix can go into version +1.

It will mean compiler bug will actually be fixed several years later and we will have another misleading dichotomy for that time. And most likely actual fix will be implemented with semantics different from ones originally discussed. I know how things work with D development.

Please, stop making compromises. It isn't politics. Outline issues, define constraints, reject partial solutions. Either stuff get fixed or it is better not touched at all until someone is ready to put in necessary effort.

Stop playing democrat. It is incompatible with open-source by design and only results in crappy technology.

On Thursday, 16 July 2015 at 15:29:41 UTC, Dicebot wrote:
> Stop playing democrat.

*democracy

On 7/15/15 8:49 PM, Mike wrote:
> 1. "AliasSeq" is no good as evident from the first post that started
> this thread

I am egging my face for starting this. Can we please return to AliasSeq? -- Andrei