consider the following code:
auto test(T : const(char)[]) (T s) { return s.length; }
void main () { assert(test(null) == 0); }
compiling this gives the following error: "no property 'length' for type 'typeof(null)'"
while i see why it complains, i think compiler should convert `null` to empty slice here, as i clearly specified the type i want to accept. sure, i can workaround this with explicit template constrain... but this is what i wanted to avoid in the first place!
also, another bug with the same `test`:
assert(test([]) == 0);
this time compiler says: "
template z01.test cannot deduce function from argument types !()(void[]), candidates are..."
i think compiler should convert empty slice to the `immutable(char)[]` here.
Comment #1 by ag0aep6g — 2016-06-30T12:34:25Z
(In reply to Ketmar Dark from comment #0)
> consider the following code:
>
> auto test(T : const(char)[]) (T s) { return s.length; }
> void main () { assert(test(null) == 0); }
>
> compiling this gives the following error: "no property 'length' for type
> 'typeof(null)'"
>
> while i see why it complains, i think compiler should convert `null` to
> empty slice here, as i clearly specified the type i want to accept. sure, i
> can workaround this with explicit template constrain... but this is what i
> wanted to avoid in the first place!
The spec [1] isn't clear on this.
The currently implemented behavior of a constraint `T : Foo` is to restrict T to those types that implicitly convert to Foo, but T is still set as usual (from an explicit argument or from IFTI).
The behavior you suggest would make it so that T is always set to Foo. Obviously, this would be a breaking change.
Both approaches are compatible with the examples in the spec, as far as I see.
In your example, you could of course just take a const(char)[] directly, without any template parameters. So that isn't a good motivating example to change the behavior.
In favor of the current behavior there is std.exception.assertThrown [2], for example. It uses a specialization to restrict T to Throwable, but it uses the (more restricted) passed T in its checks.
> also, another bug with the same `test`:
> assert(test([]) == 0);
>
> this time compiler says: "
> template z01.test cannot deduce function from argument types !()(void[]),
> candidates are..."
>
> i think compiler should convert empty slice to the `immutable(char)[]` here.
Agreed. The empty array literal [] should behave like null and the empty string literal "" here. I guess this means we need a typeof([]) that implicitly converts to any T[] (unlike void[]).
[1] http://dlang.org/spec/template.html#parameters_specialization
[2] http://dlang.org/phobos/std_exception.html#.assertThrown
Comment #2 by ketmar — 2016-06-30T12:54:19Z
(In reply to ag0aep6g from comment #1)
> In your example, you could of course just take a const(char)[] directly,
> without any template parameters. So that isn't a good motivating example to
> change the behavior.
this is common pattern in my code, actually. i want my functions to accept `string`, `const(char)[]` and `char[]` seamlessly, yet they should not do unnecessary dups when i need to copy value. that is, there is no need to dup `string` (obviously), but it's better to dup `char[]` and `const(char)[]`. without template, i can't tell if `string` or `const(char)[]` was passed.
i was so sure that compiler does conversion of `null` to empty slice that didn't even checked it beforehand. and today i was caught by the first case.