On Tuesday, 4 December 2012 at 17:43:21 UTC, 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.

 Maybe....

 I remember back when I was originally reading about C++ and overloading how the signature would let you overload a function multiple times (C++ Primer 5th I think); I was going to try making a few classes to get a good understanding only to find it.

class Something {
  long value;

  long operator+(Something& rhs) {
    return value + rhs.value;
  }

  Something operator+(Something& rhs) {
    value += rhs.value;
    return this;
  }
}

 The above would refuse to compile (and likely still does) although it has a minorly different signature; Then I came to realize the return type wasn't part of the signature, and never was part of the identifying/overload-able part of OO. It makes sense to some limited degree but it's annoying...

 In certain unique cases I wonder if having a template return type would be an answer to certain problems... We know that sometimes the compiler can rewrite 'a.func(b,c)' to 'func(a,b,c)' , it's just syntactical sugar. Why couldn't it also try (when appropriately identifiable in the signature) 't = a.func(b,c)' to 't = a.func!(typeof(t))(b, c)'?

 Mind you full template functions (where ! is required) this wouldn't apply for or even work for.

On Tuesday, 4 December 2012 at 17:43:21 UTC, 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.

 Maybe....

 I remember back when I was originally reading about C++ and overloading how the signature would let you overload a function multiple times (C++ Primer 5th I think); I was going to try making a few classes to get a good understanding only to find it.

class Something {
  long value;

  long operator+(Something& rhs) {
    return value + rhs.value;
  }

  Something operator+(Something& rhs) {
    value += rhs.value;
    return this;
  }
}

 The above would refuse to compile (and likely still does) although it has a minorly different signature; Then I came to realize the return type wasn't part of the signature, and never was part of the identifying/overload-able part of OO. It makes sense to some limited degree but it's annoying...

 In certain unique cases I wonder if having a template return type would be an answer to certain problems... We know that sometimes the compiler can rewrite 'a.func(b,c)' to 'func(a,b,c)' , it's just syntactical sugar. Why couldn't it also try (when appropriately identifiable in the signature) 't = a.func(b,c)' to 't = a.func!(typeof(t))(b, c)'?

 Mind you full template functions (where ! is required) this wouldn't apply for or even work for.

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.

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

- Jonathan M Davis

On Tuesday, 4 December 2012 at 17:43:21 UTC, 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.

 Maybe....

 I remember back when I was originally reading about C++ and overloading how the signature would let you overload a function multiple times (C++ Primer 5th I think); I was going to try making a few classes to get a good understanding only to find it. Went something like:

class Something {
  long value;

  long operator+(Something& rhs) {
    return value + rhs.value;
  }

  Something operator+(Something& rhs) {
    value += rhs.value;
    return this;
  }
}

 The above would refuse to compile (and likely still does) although it has a  different signature (or so I thought); Then I came to realize the return type wasn't part of the signature, and never was part of the identifying/overload-able part of OO. It makes sense to some limited degree but it's annoying...

 In certain unique cases I wonder if having a template return type would be an answer to certain problems... We know that sometimes the compiler can rewrite 'a.func(b,c)' to 'func(a,b,c)' , it's just syntactical sugar. Why couldn't it also try (when appropriately identifiable in the signature) 't = a.func(b,c)' to 't = a.func!(typeof(t))(b, c)'?

 Mind you full template functions (where ! is required) this wouldn't apply for or even work for.

On Tuesday, 4 December 2012 at 17:43:21 UTC, 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.

 Maybe....

 I remember back when I was originally reading about C++ and overloading how the signature would let you overload a function multiple times (C++ Primer 5th I think); I was going to try making a few classes to get a good understanding only to find it. Went something like:

class Something {
  long value;

  long operator+(Something& rhs) {
    return value + rhs.value;
  }

  Something operator+(Something& rhs) {
    value += rhs.value;
    return this;
  }
}

 The above would refuse to compile (and likely still does) although it has a  different signature (or so I thought); Then I came to realize the return type wasn't part of the signature, and never was part of the identifying/overload-able part of OO. It makes sense to some limited degree but it's annoying...

 In certain unique cases I wonder if having a template return type would be an answer to certain problems... We know that sometimes the compiler can rewrite 'a.func(b,c)' to 'func(a,b,c)' , it's just syntactical sugar. Why couldn't it also try (when appropriately identifiable in the signature) 't = a.func(b,c)' to 't = a.func!(typeof(t))(b, c)'?

 Mind you full template functions (where ! is required) this wouldn't apply for or even work for.

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

On Wednesday, December 05, 2012 22:07:48 Dmitry Olshansky wrote:
> 12/5/2012 5:40 AM, Jonathan M Davis пишет:
> > 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.

Yes, but that inevitably forces you to check the type in order to handle it correctly, which means that implicit conversion just doesn't work. In order for implicit conversion to work, you have to be able to assume that you're dealing with a particular type, and if you can do that, why are you using a Variant in the first place? Just use a common type.

> > 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?? :)

To know what on earth you're suposed to do with the variable. If it's a type that you can't handle, then yes, you'd probably have to throw an exception, but you generally use a Variant because you need to be able to return multiple types from the same function, and each is going to be treated differently, otherwise you could have just used a common type to begin with.

I just don't see how it makes any sense to implicitly convert a Variant when the only reason to use a Variant is if the types involved have no common type. Since if they no common type, you're going to have to check what it is to know what you can validly do with it.

- Jonathan M Davis

12/5/2012 11:31 PM, Jonathan M Davis пишет:
> On Wednesday, December 05, 2012 22:07:48 Dmitry Olshansky wrote:
>> 12/5/2012 5:40 AM, Jonathan M Davis пишет:
>>> 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.
>
> Yes, but that inevitably forces you to check the type in order to handle it
> correctly, which means that implicit conversion just doesn't work. In order
> for implicit conversion to work, you have to be able to assume that you're
> dealing with a particular type, and if you can do that, why are you using a
> Variant in the first place? Just use a common type.

Simply put it's the API that is more flexible the your concrete code. But there is a point in forcing the expected types as soon as possible.

In other words it's a sugar for calling Varaint.get for the type on the right. That's where the point that you don't like it while I think it could be handy.

>
>>> 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?? :)
>
> To know what on earth you're suposed to do with the variable. If it's a type
> that you can't handle, then yes, you'd probably have to throw an exception,
> but you generally use a Variant because you need to be able to return multiple
> types from the same function, and each is going to be treated differently,
> otherwise you could have just used a common type to begin with.

This is a sort of case against Varaint at large.

> I just don't see how it makes any sense to implicitly convert a Variant when
> the only reason to use a Variant is if the types involved have no common type.
> Since if they no common type, you're going to have to check what it is to know
> what you can validly do with it.

It's not. If the only reason was that I'd use an opaque "box" type.

-- 
Dmitry Olshansky

On Tuesday, 4 December 2012 at 17:43:21 UTC, 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.

 Maybe....

 I remember back when I was originally reading about C++ and overloading how the signature would let you overload a function multiple times (C++ Primer 5th I think); I was going to try making a few classes to get a good understanding only to find it. Went something like:

class Something {
  long value;

  long operator+(Something& rhs) {
    return value + rhs.value;
  }

  Something operator+(Something& rhs) {
    value += rhs.value;
    return this;
  }
}

 The above would refuse to compile (and likely still does) although it has a  different signature (or so I thought); Then I came to realize the return type wasn't part of the signature, and never was part of the identifying/overload-able part of OO. It makes sense to some limited degree but it's annoying...

 In certain unique cases I wonder if having a template return type would be an answer to certain problems... We know that sometimes the compiler can rewrite 'a.func(b,c)' to 'func(a,b,c)' , it's just syntactical sugar. Why couldn't it also try (when appropriately identifiable in the signature) 't = a.func(b,c)' to 't = a.func!(typeof(t))(b, c)'?

 Mind you full template functions (where ! is required) this wouldn't apply for or even work for.

On Wednesday, 5 December 2012 at 21:39:31 UTC, Era Scarecrow wrote:

 My god did it finally post? Sorry if it repeated a few times... Left it on easily overnight and it still didn't say it posted any of it. :(