auto limitation?

[Jonathan M Davis]

On Wednesday, September 12, 2012 00:29:32 Namespace wrote:
> You mean so?
> ref Variant get() {
>      return this._num; // with Variant _num;
> }
> 
> alias get this;
> 
> and then:
> int i = zahl.get!int?
> No. Then I use my solution as you can see on DPaste. If Variant
> works only this way I can also set float to the return type an
> cast if I need to int.
> And with my solution I have in calculation a numeric value and
> doesn't have to cast with Variant's get method.

If want the result to always be the same type, then either use the explicit 
type or auto (though clearly auto is having some issues right now, so it might 
be best to avoid it if you're returning stuff that differs in type and needs to 
be converted). If you want the result to differ in type depending on the value 
returned, then you need Variant in order to simulate dynamic typing.

I'm not quite sure what you're trying to do with your code, but if you use 
Variant, you'll need to use get or coerce to get its value from it, which it 
doesn't sound like what you want to do. If that's the case, then your get 
function needs to always return the same type - be it int or float or double or 
whatever, and you might as well just use the explicit type rather than auto, 
since it's a primitive type, not a complicated, templated one (which is the 
main reason to use auto for the return type of a function).

- Jonathan M Davis