http://wiki.dlang.org/DIP54

This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)

Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.

Thanks for your attention.

On 12/23/2013 02:39 AM, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>
> This is follow-up of several hot discussion threads that have happened
> several months ago. It has become pretty clear that there is no good way
> out of existing situation and least bad needs to be picked just to move
> forward (because it still be better than current horrible one)
>
> Linked proposal was discussed in short e-mail conversation with Andrei
> (with silent observation with Walter) and is mostly pre-approved. I am
> interested in general opinion of community and suggestions for any
> smaller tweaks before starting to work on pull requests.
>
> Thanks for your attention.

How is this going to be implemented? In a similar way as this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804

"Why that weird long name, `TemplateArgumentList`

A: Because it is exactly what it is."

Well, unfortunately template argument lists auto-expand... :o)

On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
> How is this going to be implemented? In a similar way as this?:
> https://d.puremagic.com/issues/show_bug.cgi?id=11804

Without `alias this` part (that would destroy "no auto expansion" part unless I miss something). Also I am still uncertain about implementing it as templated struct or just raw template - both have own merits and flaws, will make better comparison in process.

On 12/23/2013 03:28 AM, Dicebot wrote:
> On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
>> How is this going to be implemented? In a similar way as this?:
>> https://d.puremagic.com/issues/show_bug.cgi?id=11804
>
> Without `alias this` part (that would destroy "no auto expansion" part

No.

> unless I miss something).

std.typecons.Tuple also uses alias this.

> Also I am still uncertain about implementing
> it as templated struct or just raw template - both have own merits and
> flaws, will make better comparison in process.

I think alias this is the only way to use the static index operator.

On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP54

Are you seriously suggesting we change the auto-expanding behaviour of template argument lists? This is going to cause the biggest code breakage since D2, for the niche benefit of having lists that don't automatically expand.

This DIP makes several unfounded assumptions. It assumes that the semantics of template argument lists are inherently hard to learn, and that removing the auto-expanding aspect will make them easier to learn. It assumes that non-auto-expanding lists provide a significant usability boost, and claims that it enables previously impossible algorithms. It claims to be a compromise derived from several previous discussions (without citing any), but the only consensus I remember is that we have a naming problem. I don't remember anyone but you asking for non-expanding lists *in the language*, which I regard a red herring.

I see no proof provided for any of this.

I hate to say this, but it looks a lot like your personal agenda against auto-expanding lists is tacked onto and conflated with the naming problem, which I think is disingenuous.

> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)

I don't agree. I think we'd be in good shape just by fixing the naming problem, which is a much less controversial change.

> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.

Please don't pull the argument-by-authority card. Private conversations that affect all of us like this need to die in a fire. We should consider this kind of thing the equivalent of tainted evidence.

On Mon, Dec 23, 2013 at 01:39:24AM +0000, Dicebot wrote:
> http://wiki.dlang.org/DIP54
> 
> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)
> 
> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.
> 
> Thanks for your attention.

I approve of this proposal. Even though it's not 100% ideal, it is still better than the current situation.

People who want auto-expanding template argument lists can still do this:

	template ExpandingArgList(T...) {
		alias ExpandingArgList = T;
	}

Just like we have now.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
> People who want auto-expanding template argument lists can still do
> this:

It's not perfectly clear, but it looks to me that the DIP suggests removing the auto-expanding property of template argument lists.

On Mon, Dec 23, 2013 at 02:46:38AM +0000, Jakob Ovrum wrote:
> On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> >http://wiki.dlang.org/DIP54
> 
> Are you seriously suggesting we change the auto-expanding behaviour of template argument lists? This is going to cause the biggest code breakage since D2, for the niche benefit of having lists that don't automatically expand.
[...]

Where did you get that idea from? My understanding from reading the DIP is that we just replace std.typecons.TypeTuple, which has this definition:

	template TypeTuple(T...) {
		alias TypeTuple = T;
	}

with std.meta.list, which has this definition:

	template list(T...) {
		alias expand = T;
	}

along with the requisite documentation changes, deprecation of TypeTuple, migration of Phobos code to use std.meta.list, etc..

Nothing changes in the language itself.

Changing the language itself will basically break almost the entire Phobos, and pretty much anything that uses variadic template arguments in non-trivial ways in user code. I don't see that ever happening in D2.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
> On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
>> People who want auto-expanding template argument lists can still do
>> this:
>
> It's not perfectly clear, but it looks to me that the DIP suggests removing the auto-expanding property of template argument lists.

No, it would have changed language feature which is deeply integrated with lot of stuff and thus is untouchable. This proposal is only about Phobos and documentation.

On Monday, 23 December 2013 at 02:42:01 UTC, Timon Gehr wrote:
> On 12/23/2013 03:28 AM, Dicebot wrote:
>> On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
>>> How is this going to be implemented? In a similar way as this?:
>>> https://d.puremagic.com/issues/show_bug.cgi?id=11804
>>
>> Without `alias this` part (that would destroy "no auto expansion" part
>
> No.

Very promising then, didn't know about it. Assuming no nasty side-effects will be found it sounds like the way to go.