http://d.puremagic.com/issues/show_bug.cgi?id=752

           Summary: Assertion failure: 'e->type->ty != Ttuple' on line 4518
                    in file 'mtype.c'
           Product: D
           Version: 0.178
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: sean@f4.ca


The code:

    struct Tuple( TList... )
    {
        const size_t length = TList.length;

    private:
        typeof(TList[0])                     head;
        static if( length > 1 )
            mixin .Tuple!((TList[1 .. $]))   tail;
    }

    void main()
    {
        Tuple!(int, long) T;
        T val;
        printf( "%u\n", val.length );
    }

Gives the following errors:

    C:\code\src\d\test>dmd test
    test.d(9): Error: Integer constant expression expected instead of
cast(int)(__dollar)
    test.d(9): Error: string slice [1 .. 0] is out of bounds
    Assertion failure: 'e->type->ty != Ttuple' on line 4518 in file 'mtype.c'

    abnormal program termination

The __dollar issue can be eliminated by replacing '$' with TList.length, but the assertion failure remains.  Marking ICE on valid despite the dollar issue.


-- 

d-bugmail@puremagic.com schrieb am 2006-12-26:
> http://d.puremagic.com/issues/show_bug.cgi?id=752

> The code:
>
>     struct Tuple( TList... )
>     {
>         const size_t length = TList.length;
>
>     private:
>         typeof(TList[0])                     head;
>         static if( length > 1 )
>             mixin .Tuple!((TList[1 .. $]))   tail;
>     }
>
>     void main()
>     {
>         Tuple!(int, long) T;
>         T val;
>         printf( "%u\n", val.length );
>     }
>
> Gives the following errors:
>
>     C:\code\src\d\test>dmd test
>     test.d(9): Error: Integer constant expression expected instead of
> cast(int)(__dollar)
>     test.d(9): Error: string slice [1 .. 0] is out of bounds
>     Assertion failure: 'e->type->ty != Ttuple' on line 4518 in file 'mtype.c'
>
>     abnormal program termination
>
> The __dollar issue can be eliminated by replacing '$' with TList.length, but the assertion failure remains.  Marking ICE on valid despite the dollar issue.

Added to DStress as http://dstress.kuehne.cn/nocompile/t/tuple_09_A.d http://dstress.kuehne.cn/nocompile/t/tuple_09_B.d http://dstress.kuehne.cn/nocompile/t/tuple_09_C.d http://dstress.kuehne.cn/nocompile/t/tuple_09_D.d http://dstress.kuehne.cn/nocompile/t/tuple_09_E.d http://dstress.kuehne.cn/nocompile/t/tuple_09_F.d http://dstress.kuehne.cn/compile/t/tuple_09_G.d http://dstress.kuehne.cn/compile/t/tuple_09_H.d http://dstress.kuehne.cn/compile/t/tuple_09_I.d

Thomas

http://d.puremagic.com/issues/show_bug.cgi?id=752





------- Comment #2 from bugzilla@digitalmars.com  2006-12-29 21:43 -------
The statement:

        mixin .Tuple!((TList[1 .. $]))

is actually invalid, as it attempts to make a tuple of tuples. Instead,

        mixin .Tuple!(TList[1 .. $])

is correct. This is also wrong:

        Tuple!(int, long) T;
        T val;

as T is not declared as being a type.
The issue of length not being resolved is still a bug, though.


-- 

d-bugmail@puremagic.com wrote:
>
> ------- Comment #2 from bugzilla@digitalmars.com  2006-12-29 21:43 -------
> The statement:
> 
>         mixin .Tuple!((TList[1 .. $]))
> 
> is actually invalid, as it attempts to make a tuple of tuples. Instead,
> 
>         mixin .Tuple!(TList[1 .. $])
> 
> is correct.

This seems a slim distinction.  Adding a set of parenthesis makes the code invalid?

> This is also wrong:
> 
>         Tuple!(int, long) T;
>         T val;
> 
> as T is not declared as being a type.

Yup, I'm aware of this.  The code actually has a few bugs in it.  But it still shouldn't cause an assertion failure in the compiler.

Sean Kelly wrote:
> d-bugmail@puremagic.com wrote:
>>
>> ------- Comment #2 from bugzilla@digitalmars.com  2006-12-29 21:43 -------
>> The statement:
>>
>>         mixin .Tuple!((TList[1 .. $]))
>>
>> is actually invalid, as it attempts to make a tuple of tuples. Instead,
>>
>>         mixin .Tuple!(TList[1 .. $])
>>
>> is correct.
> 
> This seems a slim distinction.  Adding a set of parenthesis makes the code invalid?

Sure, in the same way that:

	int foo( (int, char) );

is not valid. Unless a compelling use case appears for the extra parens, I'd prefer to disallow it.

>  > This is also wrong:
>>
>>         Tuple!(int, long) T;
>>         T val;
>>
>> as T is not declared as being a type.
> 
> Yup, I'm aware of this.  The code actually has a few bugs in it.  But it still shouldn't cause an assertion failure in the compiler.

Right. That's why I haven't marked it resolved yet <g>.

Walter Bright wrote:
> Sean Kelly wrote:
>> d-bugmail@puremagic.com wrote:
>>>
>>> ------- Comment #2 from bugzilla@digitalmars.com  2006-12-29 21:43 -------
>>> The statement:
>>>
>>>         mixin .Tuple!((TList[1 .. $]))
>>>
>>> is actually invalid, as it attempts to make a tuple of tuples. Instead,
>>>
>>>         mixin .Tuple!(TList[1 .. $])
>>>
>>> is correct.
>>
>> This seems a slim distinction.  Adding a set of parenthesis makes the code invalid?
> 
> Sure, in the same way that:
> 
>     int foo( (int, char) );
> 
> is not valid. Unless a compelling use case appears for the extra parens, I'd prefer to disallow it.
> 

It would be vary handy to be able to make a member of a tuple be a tuple it's self. the perens might be a good way to denote this rather than the usual flattening.

It would allow a parser to convert a template parameter string to some sort of tuple structure. This would be vary useful for parsing things.

In fact, that was the first way I planed to do my "d sprit" implementation.

http://www.webpages.uidaho.edu/~shro8822/dsprit.d

After finding that this didn't work, I went with the "parse as you go" approach.

BCS wrote:
> It would be vary handy to be able to make a member of a tuple be a tuple it's self. the perens might be a good way to denote this rather than the usual flattening.

There's no way to do that with the current tuple semantics.

Walter Bright wrote:
> BCS wrote:
>> It would be vary handy to be able to make a member of a tuple be a tuple it's self. the perens might be a good way to denote this rather than the usual flattening.
> 
> There's no way to do that with the current tuple semantics.


I was thinking that could be a use for the extra perens

template tpl(V...)
{
	alias V tpl;
}

tpl!(a, (b, c), d);

tuple of three with a tuple of two as the second part.




p.s. while I'm thinking about features, while writing that parser generator (see my last post) I realized that allowing a template to mixin a specialization for a template and have it overload with other templates would be *vary* powerful. mixin and overload can already be done for a function by way of an alias.

I'd be interested in your thought on the subject.

BCS wrote:
> p.s. while I'm thinking about features, while writing that parser generator (see my last post) I realized that allowing a template to mixin a specialization for a template and have it overload with other templates would be *vary* powerful. mixin and overload can already be done for a function by way of an alias.
> 
> I'd be interested in your thought on the subject.

It sounds very complicated :-(

Walter Bright wrote:
> BCS wrote:
>> p.s. while I'm thinking about features, while writing that parser generator (see my last post) I realized that allowing a template to mixin a specialization for a template and have it overload with other templates would be *vary* powerful. mixin and overload can already be done for a function by way of an alias.
>>
>> I'd be interested in your thought on the subject.
> 
> It sounds very complicated :-(


What about it?

If you are referring to the parser code:
	Most of it is string manipulation templates. The last template
	is just parser for a sudo-BNF and a brain dead implementation of
	that grammar.

	As bad is this implementation is, I think it still beats the
	~1.5MB of code it takes in C++.



If you are referring to allowing overloading of specializations from mixins:
	here is a short example of what it would looks like:

template Foo(int i, char[] str)
{
	int Bar(char[] a: str)(int j)
	{
		return j+i;
	}
}

template Fig(int i, char[] str)
{
	int Bar(char[] a: str)(int j)
	{
		return j-i;
	}
}

struct Fog
{
	mixin Foo!(1, "hi") A
	alias A.Bar Bar;
	// having an implicit form of the alias would be VARY nice.
	// maybe: alias mixin Foo!(1, "hi");

	mixin Fig!(1, "bye") B
	alias B.Bar Bar;

	auto i = Bar!("hi")(3);	// uses Bar from Foo giving 4
	auto j = Bar!("bye")(3);// uses Bar from Fig giving 2
}

The other important thing that would make this vary powerfully is a way to allow forward reference to specializations. This would let mixins reference code in other mixins by knowing the name of the template to be used and the string to specialize it on.


void DoActionList(char[] str)()
{
	foreach(a; SplitOn!(',', str))
		Action!(a)();
}

DoActionList!("Fig,Farm,Foe")();
	// does Action!("fig"),  Action!("farm"),  Action!("foe");

mixin Baz!("fig"); // adds Action(char[] : "fig")


The importance of forward reference comes when cyclical calling is needed, as with a recursive decent parser.