Template return values?

[Dmitry Olshansky]

12/5/2012 5:40 AM, Jonathan M Davis пишет:
> On Tuesday, December 04, 2012 23:28:25 Dmitry Olshansky wrote:
>> 12/4/2012 10:40 PM, Jonathan M Davis пишет:
>>> On Tuesday, December 04, 2012 21:43:09 Dmitry Olshansky wrote:
>>>> Well TDPL claims multiple alias this is allowed so in some distant
>>>> future it maybe possible for Varaint to alias this to all built-in types.
>>>
>>> That would be pretty hideous IMHO. There's a reason that D eschews
>>> implicit
>>> conversions in general. And in this case, you'd very quickly end up with
>>> accidental conversions which resulted in exceptions being thrown by
>>> Variant.
>> Examples?
>
> Unlike C++, no implicit conversion occurs via constructors. In C++, you get up
> to three implicit conversions when matching function parameters. In D, without
> alias this, you get 0. C++ has way more places where it allows implicit
> conversions than D does. D has very few.
>
> If you start letting Variants implicitly convert, then you get problems like
>
> int i = v;
>
> throwing an exception because v holds a string - or a user defined type which
> can't convert to int.

So what? I hardly see it as a problem.

In the spirit of being dynamic Variant ought to use to! function inside. 
Thus string can be converted to an int. I'm not big fun of such scripty 
way of doing things but it has uses.

The problematic thing are overloads:
void func(double d);
void func(int);

func(Varaint(3.14));

---> ambiguous

>>> I think that it's _much_ better to require explicit conversions from
>>> Variant.
>> Nope. The point of Variant is to feel natural.
>
> There's nothing natural about Variant. It's attempting to add dynamic typing
> to a statically typed language.

Bleh that smells religious. There are cases where one may just go for it 
to simplify matters. Spreadsheets, Db rows and whatnot often operate in 
Variants. Simply because one can't know ahead of time what the content 
is in a arbitrary DB.

> And as you can't know what it's type really is
> at compile time, all conversions require type checking at runtime. And
> implicit conversions must be determined at compile time. So really, the
> implicit conversions make no sense at all.

> And I would generally expect that
> code would have to check the type of a Variant before doing a conversion -

to do what? throw an Exception?? :)

Another case would be doing a type-switch but there is little amount of 
code that deals with many types. Most commonly they assume type or kind 
of type.

> otherwise it's bound to throw an exception a good portion of the time - so
> implicit conversions make that much less sense.

I just think that for majority of cases it's going to be check and throw 
on bad conversion.


-- 
Dmitry Olshansky