• bearophile (30/30) Jul 14 2011 A D2 program:
• Daniel Murphy (12/47) Jul 14 2011 Yeah, type deduction with modifiers is inconsistent.
• bearophile (4/10) Jul 14 2011 Is this already in Bugzilla, or do you want me to create a new Bugzilla ...
• Daniel Murphy (3/14) Jul 14 2011 I don't think there's a bug report specifically on this.

bearophile <bearophileHUGS lycos.com> writes:

A D2 program:


T[] foo(T)(const T[] x) {
    //static assert(is(U == int)); // false
    static assert(is(T == const(int)));
    return new T[1];
}
U[] bar(U)(const U[] y) {
    static assert(is(U == int));
    return foo(y);
}
void main() {
    bar([1]);
}


DMD 2.054 gives:
test.d(8): Error: cannot implicitly convert expression (foo(y)) of type
const(int)[] to int[]
test.d(11): Error: template instance test.bar!(int) error instantiating


Do you know why T of foo is const(int) instead of int? Isn't the "const" of
foo(T)(const T[] x) de-structuring the const nature of x? Is is possible to
change/"fix" this?

This causes me problems because many of my functions have "in" arguments. When
they call each other they don't compile, as in this example (here I have used
"const" arguments just for clarity).


I have had to use code like this:

Unqual![] foo(T)(const T[] x) {
    return new Unqual!T[1];
}
U[] bar(U)(const U[] y) {
    return foo(y);
}
void main() {
    bar([1]);
}

Bye and thank you,
bearophile

"Daniel Murphy" <yebblies nospamgmail.com> writes:

Yeah, type deduction with modifiers is inconsistent.

In some cases matching T to const(U) gives U == tailconst(T), but not in 
others.
The problem exists with pointers, arrays, and (if we ever get it) Michel 
Fortin's const(Object)ref.

A big part of the problem is that it can match with implicit conversions, 
but the type is never actually converted.

eg.
is(shared(int*) T : const(U), U) should match and give U == 
shared(const(int)*)

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ivmd15$2vp2$1 digitalmars.com...
A D2 program:


 T[] foo(T)(const T[] x) {
    //static assert(is(U == int)); // false
    static assert(is(T == const(int)));
    return new T[1];
 }
 U[] bar(U)(const U[] y) {
    static assert(is(U == int));
    return foo(y);
 }
 void main() {
    bar([1]);
 }


 DMD 2.054 gives:
 test.d(8): Error: cannot implicitly convert expression (foo(y)) of type 
 const(int)[] to int[]
 test.d(11): Error: template instance test.bar!(int) error instantiating


 Do you know why T of foo is const(int) instead of int? Isn't the "const" 
 of foo(T)(const T[] x) de-structuring the const nature of x? Is is 
 possible to change/"fix" this?

 This causes me problems because many of my functions have "in" arguments. 
 When they call each other they don't compile, as in this example (here I 
 have used "const" arguments just for clarity).


 I have had to use code like this:

 Unqual![] foo(T)(const T[] x) {
    return new Unqual!T[1];
 }
 U[] bar(U)(const U[] y) {
    return foo(y);
 }
 void main() {
    bar([1]);
 }

 Bye and thank you,
 bearophile 

bearophile <bearophileHUGS lycos.com> writes:

Daniel Murphy:

 Yeah, type deduction with modifiers is inconsistent.
 
 In some cases matching T to const(U) gives U == tailconst(T), but not in 
 others.
 The problem exists with pointers, arrays, and (if we ever get it) Michel 
 Fortin's const(Object)ref.

Is this already in Bugzilla, or do you want me to create a new Bugzilla
enhancement request with my examples?

Bye,
bearophile

"Daniel Murphy" <yebblies nospamgmail.com> writes:

I don't think there's a bug report specifically on this.

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ivmigl$98a$1 digitalmars.com...
 Daniel Murphy:

 Yeah, type deduction with modifiers is inconsistent.

 In some cases matching T to const(U) gives U == tailconst(T), but not in
 others.
 The problem exists with pointers, arrays, and (if we ever get it) Michel
 Fortin's const(Object)ref.

 Is this already in Bugzilla, or do you want me to create a new Bugzilla 
 enhancement request with my examples?

 Bye,
 bearophile