Why doesn't the following code work in D2 (it works in D1)?
void foo (T) (in T[] a, T b)
{
}
void main ()
{
"asd".foo('s');
}
The error I get is:
main.d(10): Error: template main.foo(T) does not match any function
template declaration
main.d(10): Error: template main.foo(T) cannot deduce template function
from argument types !()(string,char)
It seems to be some problem with the "b" argument, if I change that to
"char" it works.
--
/Jacob Carlborg

Why doesn't the following code work in D2 (it works in D1)?
void foo (T) (in T[] a, T b)
{
}
void main ()
{
"asd".foo('s');
}
The error I get is:
main.d(10): Error: template main.foo(T) does not match any function
template declaration
main.d(10): Error: template main.foo(T) cannot deduce template function
from argument types !()(string,char)
It seems to be some problem with the "b" argument, if I change that to
"char" it works.

Why doesn't the following code work in D2 (it works in D1)?
void foo (T) (in T[] a, T b)
{
}
void main ()
{
"asd".foo('s');
}
The error I get is:
main.d(10): Error: template main.foo(T) does not match any function
template declaration
main.d(10): Error: template main.foo(T) cannot deduce template
function from argument types !()(string,char)
It seems to be some problem with the "b" argument, if I change that to
"char" it works.

That's annoying, specially since "char" is a value type. I would
preferably have a solution for both D1 and D2. Can I use a template to
cast/alias away the immutable part?

One solution would be to have templates strip off const/immutable from the
top level of args.
void F1(T)(T t) { pragam(msg,typeof(t).stringof); }
string s1;
immutable(char[]) s2
char[] s3
F1(s1); // immutable(char)[] // all as normal
F1(s2); // immutable(char)[] // making a mutable copy of a immutable value
is OK
F1(s3); // char[] // all as normal
void F2(T)(immutable T t) { pragam(msg,typeof(t).stringof); }
F2(s1); // immutable(char[]) // making an immutable copy of a mutable reference
to immutable data is ok
F2(s2); // immutable(char[]) // all as normal
F2(s3); // error, invalid conversion
This solution would match the proposal that popped up a while ago to allow
value assignment from const/immutable to mutable.
--
... <IXOYE><

That's annoying, specially since "char" is a value type. I would
preferably have a solution for both D1 and D2. Can I use a template to
cast/alias away the immutable part?

One solution would be to have templates strip off const/immutable from
the top level of args.
void F1(T)(T t) { pragam(msg,typeof(t).stringof); }
string s1;
immutable(char[]) s2
char[] s3
F1(s1); // immutable(char)[] // all as normal
F1(s2); // immutable(char)[] // making a mutable copy of a immutable
value is OK
F1(s3); // char[] // all as normal
void F2(T)(immutable T t) { pragam(msg,typeof(t).stringof); }
F2(s1); // immutable(char[]) // making an immutable copy of a mutable
reference to immutable data is ok
F2(s2); // immutable(char[]) // all as normal
F2(s3); // error, invalid conversion
This solution would match the proposal that popped up a while ago to
allow value assignment from const/immutable to mutable.

I don't think I understand what you're showing here. How would I strip
off the const/immutable with a template ?
--
/Jacob Carlborg

On Mon, Jun 28, 2010 at 10:56, Jacob Carlborg <doob me.com> wrote:
Something to keep in mind: as of 2.04x (.045? maybe), the way UTF-8 / UTF-32
is managed was changed. "asd" is an array of immutable(dchar), not
imutable(char). At least DMD tells me that its element type is 'dchar'.
So your function can be done this way in D2:
void foo(T,U)(in T[] a, U b) if (is(U : Unqual!T)) // that compiles only if
b can be cast to A
{
writeln(a,b);
}
"asd".foo('s'); // prints "asds".
is(U == Unqual!T) does not work, for U is 'char' while Unqual!T is 'dchar'.
More generally, using ranges and not arrays, the template becomes a bit more
heavy:
void foo(Range,Elem)(in Range range, Elem elem)
if (isInputRange!Range && is(Elem : Unqual!(ElementType!Range)))
{
...
}
I don't think I understand what you're showing here. How would I strip off

On Mon, Jun 28, 2010 at 10:56, Jacob Carlborg <doob me.com> wrote:
Something to keep in mind: as of 2.04x (.045? maybe), the way UTF-8 /
UTF-32
is managed was changed. "asd" is an array of immutable(dchar), not
imutable(char). At least DMD tells me that its element type is 'dchar'.

No, that is not true. It's still an array of immutable(char). The
compiler still sees it as an array of immutable(char). However, std.range
forces the element type of char[] and wchar[] to be bidirectional ranges
of dchar. The tests such as isRandomAccessRange and ElementType are
fudged to say string is *not* a random access range, and its element type
is dchar. This was one of Andrei's changes because without such
shoehorning, std.algorithm could possible start shearing off strings that
weren't valid.
Whether that was the right decision remains to be seen. I personally
would rather have special ranges that do those things. If I have a string
that's always in English, why do I need to generate the dchars based on
the characters in that array?
-Steve

Something to keep in mind: as of 2.04x (.045? maybe), the way UTF-8 /
UTF-32
is managed was changed. "asd" is an array of immutable(dchar), not
imutable(char). At least DMD tells me that its element type is 'dchar'.

No, that is not true. It's still an array of immutable(char). The
compiler still sees it as an array of immutable(char). However, std.range
forces the element type of char[] and wchar[] to be bidirectional ranges of
dchar. The tests such as isRandomAccessRange and ElementType are fudged to
say string is *not* a random access range, and its element type is dchar.
This was one of Andrei's changes because without such shoehorning,
std.algorithm could possible start shearing off strings that weren't valid.

Ah yes, indeed, you're right.

Whether that was the right decision remains to be seen. I personally would
rather have special ranges that do those things. If I have a string that's
always in English, why do I need to generate the dchars based on the
characters in that array?

All that I can say is that it instantly broke dozens of unit tests in my
projects, which were using strings a simple random-access ranges. It took me
2 DMD releases to work my way uout of it.
Maybe I should have a look at byCodeUnit or somesuch. But for clueless users
like me, strings suddenly became much more complicated to use. Maybe I was
using them in unsafe ways, I don't know. I just hope for a way to get my
simple strings back.

One solution would be to have templates strip off const/immutable
from the top level of args.

[...]

This solution would match the proposal that popped up a while ago to
allow value assignment from const/immutable to mutable.

I don't think I understand what you're showing here. How would I strip
off the const/immutable with a template ?

I was proposing a language change Sorry for any confusion. The idea is that
unless the user ask for it explicitly, there is no particular reason to
preserve
const/immutable for the value portion (true value types and the first level
of references/pointers) of arguments.
--
... <IXOYE><

One solution would be to have templates strip off const/immutable
from the top level of args.

[...]

This solution would match the proposal that popped up a while ago to
allow value assignment from const/immutable to mutable.

I don't think I understand what you're showing here. How would I strip
off the const/immutable with a template ?

I was proposing a language change Sorry for any confusion. The idea is
that unless the user ask for it explicitly, there is no particular
reason to preserve const/immutable for the value portion (true value
types and the first level of references/pointers) of arguments.