Deduce template arguments from return value?
Idan Arye via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jul 12 09:03:25 PDT 2015
On Sunday, 12 July 2015 at 14:13:22 UTC, Timon Gehr wrote:
> On 07/12/2015 02:52 PM, Idan Arye wrote:
>> [...]
>
> 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.
That's a good point, which raises quite a concern - if this type
inference is used in a templated function, the function will work
with simple template parameters(ones that the deduction system
can handle) but not with complex ones(e.g. ones that use auto
return type). This will make development of these templates
harder, because you won't be able to test them with simple
parameters...
More information about the Digitalmars-d
mailing list