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

Reply via email to