View mode: basic / threaded / horizontal-split · Log in · Help
December 04, 2012
Re: Template return values?
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.
December 05, 2012
Re: Template return values?
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.
December 05, 2012
Re: Template return values?
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
December 05, 2012
Re: Template return values?
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.
December 05, 2012
Re: Template return values?
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.
December 05, 2012
Re: Template return values?
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
December 05, 2012
Re: Template return values?
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
December 05, 2012
Re: Template return values?
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
December 05, 2012
Re: Template return values?
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.
December 05, 2012
Re: Template return values?
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. :(
1 2 3
Top | Discussion index | About this forum | D home