www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - A problem with const

reply 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
Jul 14 2011
parent reply "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 

Jul 14 2011
parent reply 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
Jul 14 2011
parent "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

Jul 14 2011