Deduce template arguments from return value?

[Timon Gehr via Digitalmars-d]

On 07/12/2015 02:52 PM, Idan Arye wrote:
> On Sunday, 12 July 2015 at 09:13:03 UTC, Yuxuan Shui wrote:
>> For example:
>> import std.conv;
>> T a(T)(int a) {
>>     return to!T(a);
>> }
>> void main(){
>>     string x = a(2);
>> }
>>
>> D is not able to deduce T. Can we make it possible to deduce template
>> arguments from where the return value is assigned to?
>>
>> Rust is able to do this:
>> fn main() {
>>     let a : Vec<i32> = Vec::new();
>> }
>>
>> (In fact, you can even do this is Rust:
>> fn main() {
>>     let mut a = Vec::new();
>>     a[0] = 0i32;
>> })
>
> Just like ML, Rust's amazing type inference comes with a price - a super
> strict type system. D has less strict type system, which allows - for
> example - implicit conversions in some cases(consider
> http://dpaste.dzfl.pl/ed83a75a48ba)
>
> For D to support Rust's kind of type inference, it's type system will
> need to be completely replaced with something much more strict. Whether
> you think such type systems are good or not - this change will result in
> a massive code breakage.

Strictness is not really the main problem here. Even if your language 
supports implicit conversions/overloading, the language can just give 
you back an error in case of unresolvable ambiguity as in your example. 
The example given in the OP has as obvious correct answer `string`, even 
though `const(string)` would in principle be possible as well.

It is more about the issue that D's type system is Turing complete, 
hence it is hard to come up with a very principled set of deduction 
rules. Maybe something like: "If the computation of the return type does 
not involve introspection on any unspecified template argument, template 
arguments can be deduced from the return type."

Implementation is roughly: If an IFTI call has unresolved arguments, but 
there are restrictions on the return type, instantiate all remaining 
overloads of the template with wildcard arguments that resist any kind 
of introspection and analyze everything possible, ignoring template 
constraints and gagging any compilation errors. As soon as the return 
types for every overload have been determined in terms of the wildcards, 
unify them with what you know about the required return type and check 
the template constraints in an attempt to remove the remaining 
ambiguity. Error out if anything remains ambiguous.