On 12/30/2013 07:26 PM, Timon Gehr wrote:
>      assert(y==Seq!(3,4.0)); int x;

(Ignore the 'x' :o).)

On 12/30/2013 07:43 AM, Andrei Alexandrescu wrote:
>>>
>>> Template arguments lists are what they are - entities that can be passed
>>> to templates. Aliasing them is sensible but creating values thereof does
>>> not make sense.
>>
>> You are doing it in the implementation of std.typecons.Tuple, and on
>> every variadic function template call. How does it not make sense?
>
> This is a misunderstanding.

I guess this is a matter of exposition rather than understanding.

> I don't know how to clear it.

Usually, by communication.

On 12/30/13 10:31 AM, Timon Gehr wrote:
> On 12/30/2013 07:43 AM, Andrei Alexandrescu wrote:
>>>>
>>>> Template arguments lists are what they are - entities that can be
>>>> passed
>>>> to templates. Aliasing them is sensible but creating values thereof
>>>> does
>>>> not make sense.
>>>
>>> You are doing it in the implementation of std.typecons.Tuple, and on
>>> every variadic function template call. How does it not make sense?
>>
>> This is a misunderstanding.
>
> I guess this is a matter of exposition rather than understanding.

Yah, I was the one who misunderstood.

Andrei

On Monday, 23 December 2013 at 01:39:26 UTC, 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.

Short update - I am going to try to implement PR for dmd which will allow template argument opSlice & friends (and thus hygienic packed typed), will return to this topic once it is figured out.

On Monday, 23 December 2013 at 01:39:26 UTC, 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.

Small update on this.

I have chosen to go route of investigating compiler enhancement possibilities first to allow cleaner argument pack implementation. After some tweaks it was relatively easy to make work these two samples:

-----
struct X
{
    static int opSlice(size_t l, size_t u) { return l + u; }
}

pragma(msg, X[1..2]);
-----

and

-----
struct X
{
    // note the template args
    static auto opSlice(size_t l, size_t u)() { return l + u; }
}

pragma(msg, X[1..2]);
-----

However I am still struggling with more practical example:

-----
struct X(T...)
{
    static auto opSlice(size_t l, size_t u)() { return X!(T[l..u]); }
}

alias Y = (X!(1, 2, 3))[1..2];
-----

It seems to take completely different processing path, one that does not allow obvious syntax rewriting before semantic pass. I think I'll throw few more weeks into trying this and proceed with crappy alternative upon failure.

On Monday, 23 December 2013 at 23:24:30 UTC, Andrei Alexandrescu
wrote:
> On 12/23/13 4:25 AM, Dicebot wrote:
>> On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
>>> Can we add alias for `auto-expansion TypeTuple` and add link to the
>>> previous documentation like this:
>>>
>>> alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
>>>
>>> It looks like it can fix all objections here.
>>
>> What is this supposed to give over just using .expand directly? I have
>> not seen a good rationale that justifies it among existing objections,
>> probably have missed it.
>
> I also think that implicit expansion should not be frequent enough to justify its own abstraction.
>
> Andrei

The thing is that you can build non expanding tuples on top of
expanding ones, not the other way around. So I think the language
should have buitin expanding tuples (and renamed something else
than tuple).

On Thursday, 16 January 2014 at 19:15:49 UTC, deadalnix wrote:
> The thing is that you can build non expanding tuples on top of
> expanding ones, not the other way around. So I think the language
> should have buitin expanding tuples (and renamed something else
> than tuple).

Wait what?

template ExpandingArgList(T...) // assuming T is non-expanding
{
    alias ExpandingArgList = T.expand;
}

On Monday, 20 January 2014 at 12:36:04 UTC, Dicebot wrote:
> On Thursday, 16 January 2014 at 19:15:49 UTC, deadalnix wrote:
>> The thing is that you can build non expanding tuples on top of
>> expanding ones, not the other way around. So I think the language
>> should have buitin expanding tuples (and renamed something else
>> than tuple).
>
> Wait what?
>
> template ExpandingArgList(T...) // assuming T is non-expanding
> {
>     alias ExpandingArgList = T.expand;
> }

The auto expand require compiler support. The non expanding behavior can be modeled on top of the auto expanding one.

The problem we have goes as follow to me:
 - We call the expanding construct tuple, which confuse everybody.
 - We lack some syntactic sugar to auto expand tuples. I proposed a solution for auto unpacking random stuffs.

I do think this approach is superior.

On Monday, 20 January 2014 at 20:40:30 UTC, deadalnix wrote:
> The auto expand require compiler support.

Yes. And has nothing to do with actual list behavior.

> The non expanding behavior can be modeled on top of the auto expanding one.

Unfortunately not right now. Not cleanly at least. I am working on it.

> The problem we have goes as follow to me:
>  - We call the expanding construct tuple, which confuse everybody.

It is irrelevant topic. I think TemplateArgumentList and TemplateArgumentPack are a good names.

>  - We lack some syntactic sugar to auto expand tuples. I proposed a solution for auto unpacking random stuffs.

Nope. We lack lot of syntactic sugar for packs. All we have is for expanding built-in ones.

Auto-unpacking and all similar extra yummies is completely orthogonal and unrelated topic I don't even want to touch.

> I do think this approach is superior.

It is simply unrelated and can be added on top of any outcome.

Have updated the DIP to include feedback from this thread : http://wiki.dlang.org/DIP54

It effectively means resorting back to both std.meta.pack and std.meta.list as a compromise.

Unfortunately I was not able to hack compiler into doing opSlice overloading desired for hygienic TemplateArgumentPack implementation. opSlice itself is doable but I have a big problem with existing opDollar implementation which effectively replaces $ with a reference to local variable __dollar__ making it impossible to use one in contexts where no hidden variable can be injected. Restructuring frontend to use different opDollar semantics is beyond my current knowledge and I want to move forward with it.

Hope to start working on it soon. Ironically, getting a D job has stripped me of almost all time spent on side D tasks so progress is very slow, sorry :(