On Monday, 30 December 2013 at 03:37:56 UTC, Timon Gehr wrote:
>> It is in line with general rule of opXXX for structs working as syntax
>> rewrite.
>
> No, it is not.

"No" as in "not in line" or "you interpret rules wrong"?

>> Me too. Maybe it should be addressed in general by defining
>> template-argument opXXX - than it is subject of own DIP indeed. It is
>> not critical for this DIP implementation so I did not think about it in
>> details but it can make implementation much more hygienic.
>
> It's critical if you want to support the real opSlice.

What do you mean by "real"? Naive alias this implementation will be sliceable. Problem is without this feature it will degenerate into raw argument list upon slicing which is not clean but not fatal (still an improvement over existing TypeTuple)

On Monday, 30 December 2013 at 04:07:42 UTC, Timon Gehr 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?

See my clarification here - http://forum.dlang.org/post/msumrnieryzifgcyuiqc@forum.dlang.org

It is not creation of instance in general language meaning, it is special case implemented specifically for template argument lists which just happen to look so naturally close to instantiation. In fact it creates new template argument lists of aliases to variables, one can do the same trick manually with named variables with exactly same effect.

On 12/30/2013 05:11 AM, Dicebot wrote:
> On Monday, 30 December 2013 at 04:07:42 UTC, Timon Gehr 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?
>
> See my clarification here -
> http://forum.dlang.org/post/msumrnieryzifgcyuiqc@forum.dlang.org
>
> It is not creation of instance in general language meaning, it is
> special case implemented specifically for template argument lists which
> just happen to look so naturally close to instantiation. In fact it
> creates new template argument lists of aliases to variables, one can do
> the same trick manually with named variables with exactly same effect.

Just to get your assumption that I am confused out of the way, I am fully aware how this is most easily implemented (in fact, I _have_ implemented it in my own partly-finished D programming language frontend.)

If you are going to claim that this is not proper creation of an instance of a type, except that:

int x;
static assert(is(typeof(x)==int));

Seq!(int, double) y;
static assert(is(typeof(y)==Seq!(int, double))); // presumably "bad"

Then I don't know what to tell you. It is not useful at all to make a terminological distinction between the two cases above and claim that one is somehow special and confusing, when everything actually behaves in an uniform way.

On 12/30/2013 05:08 AM, Dicebot wrote:
> On Monday, 30 December 2013 at 03:37:56 UTC, Timon Gehr wrote:
>>> It is in line with general rule of opXXX for structs working as syntax
>>> rewrite.
>>
>> No, it is not.
>
> "No" as in "not in line" or "you interpret rules wrong"?
> ...

Both. There is no precedent for rewriting operator arguments to template value arguments neither in the spec, in newsgroup discussions on the design of a potential feature, nor in the implementation. You seemed to claim this is merely a compiler bug and this can be deduced from the spec by analogy, so you also appear to interpret rules wrong.

>>> Me too. Maybe it should be addressed in general by defining
>>> template-argument opXXX - than it is subject of own DIP indeed. It is
>>> not critical for this DIP implementation so I did not think about it in
>>> details but it can make implementation much more hygienic.
>>
>> It's critical if you want to support the real opSlice.
>
> What do you mean by "real"?

The one that actually gives you a Pack back.

> Naive alias this implementation will be
> sliceable. Problem is without this feature it will degenerate into raw
> argument list upon slicing which is not clean but not fatal (still an
> improvement over existing TypeTuple)

Questionable. Slicing is a common operation.

On Monday, 30 December 2013 at 04:25:22 UTC, Timon Gehr wrote:
> If you are going to claim that this is not proper creation of an instance of a type, except that:
>
> int x;
> static assert(is(typeof(x)==int));
>
> Seq!(int, double) y;
> static assert(is(typeof(y)==Seq!(int, double))); // presumably "bad"
>
> Then I don't know what to tell you. It is not useful at all to make a terminological distinction between the two cases above and claim that one is somehow special and confusing, when everything actually behaves in an uniform way.

Same as type list is not type but list of types, expression list is not an instance but list of aliases to instances. This is important distinction terminology-wise at least and pretty much the reason this thing has no ABI which is huge semantical thing on its own.

I'd love it to be designed and implemented in such way (I have even posted such proposal in past) but it is not the case for both DMD and spec right now. I am not an expert in DMD internals so I am taking Don's word on this (we have been talking on this topic some time ago in person).

On Monday, 30 December 2013 at 04:35:04 UTC, Timon Gehr wrote:
> Both. There is no precedent for rewriting operator arguments to template value arguments neither in the spec, in newsgroup discussions on the design of a potential feature, nor in the implementation. You seemed to claim this is merely a compiler bug and this can be deduced from the spec by analogy, so you also appear to interpret rules wrong.

Ah I was referring to the fact that it does not seem to compile even assuming normal non-template parameters as indexes (which looks like a bug). Other part (which is real desired one) is not allowed by spec right now indeed.

struct X
{
	static int opSlice(size_t a, size_t b)
	{
		return 42;
	}
}

static assert ( X[1..2] == 42 );

// Error: cannot slice type 'X'

I expected this one to work.

>> Naive alias this implementation will be
>> sliceable. Problem is without this feature it will degenerate into raw
>> argument list upon slicing which is not clean but not fatal (still an
>> improvement over existing TypeTuple)
>
> Questionable. Slicing is a common operation

Sure and I am going to try it. But it is not a showstopper for DIP in question I think.

On 12/30/2013 05:55 AM, Dicebot wrote:
>
> Ah I was referring to the fact that it does not seem to compile even
> assuming normal non-template parameters as indexes (which looks like a
> bug). Other part (which is real desired one) is not allowed by spec
> right now indeed.
>
> struct X
> {
>      static int opSlice(size_t a, size_t b)
>      {
>          return 42;
>      }
> }
>
> static assert ( X[1..2] == 42 );
>
> // Error: cannot slice type 'X'
>
> I expected this one to work.

Ah, I see.

On 12/30/2013 05:51 AM, Dicebot wrote:
> On Monday, 30 December 2013 at 04:25:22 UTC, Timon Gehr wrote:
>> If you are going to claim that this is not proper creation of an
>> instance of a type, except that:
>>
>> int x;
>> static assert(is(typeof(x)==int));
>>
>> Seq!(int, double) y;
>> static assert(is(typeof(y)==Seq!(int, double))); // presumably "bad"
>>
>> Then I don't know what to tell you. It is not useful at all to make a
>> terminological distinction between the two cases above and claim that
>> one is somehow special and confusing, when everything actually behaves
>> in an uniform way.
>
> Same as type list is not type but list of types,

Both.

> expression list is not an instance but list of aliases to instances.

Both.

> This is important distinction terminology-wise at least

I don't think the terms are mutually exclusive. D eliminates the distinction.

> and pretty much the reason this thing has no ABI which is huge semantical thing on its own.
> ...

The reason it has no ABI is that it cannot be returned from functions. (Which the spec mentions as a TODO and I support as a non-standard extension.)

> I'd love it to be designed and implemented in such way (I have even
> posted such proposal in past) but it is not the case for both DMD and
> spec right now. I am not an expert in DMD internals so I am taking Don's
> word on this (we have been talking on this topic some time ago in person).

I think both the spec and the external behaviour of DMD support the viewpoint that type lists are also types.

On 12/29/13 8:03 PM, Dicebot wrote:
> It is yet another special case that makes template argument list act as
> first class type despite not being one.

Oh, I see. Yah, that's odd but then such is life. I think it's a tolerable special case.

> If it is you judgement, let it be so. I prefer to start working on
> implementation whatever it is as opposed to endless discussion. What is
> your opinion about defining general guideline to use packs over nested
> templates for multi-list algorithms (another disagreement between me and
> Jakob)?

I think an argument advocating a bunch of changes that add chaff to code that works very well would have a hard time geting off the ground. Use the right tool for the job - that's why we're providing two of them.


Andrei

On 12/29/13 8:07 PM, Timon Gehr wrote:
> On 12/30/2013 04:44 AM, Andrei Alexandrescu wrote:
>>
>> I don't understand the question. I think there's no particular relation
>> between TemplateArgument{List,Pack}!(int, double) and
>> TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the
>> other is a list of two values, and yah, if you map typeof over the
>> arguments in the latter it so happens you get the types in the first.
>>
>> 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 don't know how to clear it.

Andrei