www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Template return values?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  A thought's been going through my head for a while now. I wonder 
about template return values. Function signatures are usually the 
inputs and NOT the return type. However for writing a variant 
type could be so very useful. So unless I've misunderstood, this 
doesn't work (but it would be cool if it did).

struct Variant {
   enum ValueType {Long, Float, Double}

   ValueType vt;
   union {
     long lng;
     float fl;
     double dbl;
   }

   T getValue(T)()  property
   if (T == long || T == float || T == double) { //allowable types
     static if (T == long) { //only long case written for brevity
       switch(vt) {
         //entries would likely be mixed in and not written 
manually...
         case Long: return lng;
         case Float:
           assert(lng >= float.min && lng <= float.max);
           return cast(float) lng;
         case Float:
           assert(lng >= double.min && lng <= double.max);
           return cast(double) lng;
       }
     }

     assert(0, "Fell through, should never get here");
   }
}


  So then in theory

  Variant v;
  int i = v.getValue; //calls getValue!int()
Dec 03 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-04 08:48, Era Scarecrow wrote:
   A thought's been going through my head for a while now. I wonder about
 template return values. Function signatures are usually the inputs and
 NOT the return type. However for writing a variant type could be so very
 useful. So unless I've misunderstood, this doesn't work (but it would be
 cool if it did).

 struct Variant {
    enum ValueType {Long, Float, Double}

    ValueType vt;
    union {
      long lng;
      float fl;
      double dbl;
    }

    T getValue(T)()  property
    if (T == long || T == float || T == double) { //allowable types
      static if (T == long) { //only long case written for brevity
        switch(vt) {
          //entries would likely be mixed in and not written manually...
          case Long: return lng;
          case Float:
            assert(lng >= float.min && lng <= float.max);
            return cast(float) lng;
          case Float:
            assert(lng >= double.min && lng <= double.max);
            return cast(double) lng;
        }
      }

      assert(0, "Fell through, should never get here");
    }
 }


   So then in theory

   Variant v;
   int i = v.getValue; //calls getValue!int()
You can use "alias this", but that only works for one type. http://dlang.org/class.html#AliasThis -- /Jacob Carlborg
Dec 04 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/4/2012 4:08 PM, Jacob Carlborg пишет:
 On 2012-12-04 08:48, Era Scarecrow wrote:
   A thought's been going through my head for a while now. I wonder about
 template return values. Function signatures are usually the inputs and
 NOT the return type. However for writing a variant type could be so very
 useful. So unless I've misunderstood, this doesn't work (but it would be
 cool if it did).

 struct Variant {
    enum ValueType {Long, Float, Double}

    ValueType vt;
    union {
      long lng;
      float fl;
      double dbl;
    }

    T getValue(T)()  property
    if (T == long || T == float || T == double) { //allowable types
      static if (T == long) { //only long case written for brevity
        switch(vt) {
          //entries would likely be mixed in and not written manually...
          case Long: return lng;
          case Float:
            assert(lng >= float.min && lng <= float.max);
            return cast(float) lng;
          case Float:
            assert(lng >= double.min && lng <= double.max);
            return cast(double) lng;
        }
      }

      assert(0, "Fell through, should never get here");
    }
 }


   So then in theory

   Variant v;
   int i = v.getValue; //calls getValue!int()
You can use "alias this", but that only works for one type. http://dlang.org/class.html#AliasThis
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. -- Dmitry Olshansky
Dec 04 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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. I think that it's _much_ better to require explicit conversions from Variant. - Jonathan M Davis
Dec 04 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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?
 I think that it's _much_ better to require explicit conversions from Variant.
Nope. The point of Variant is to feel natural. Keep in mind that alias this is highly customizable. I'd expect it to do safe narrowing conversions and being only r-value so it will work just fine. auto x = someVaraint; //NP: x is Varaint ushort a = x; // implicit conversion that throws on narrowing x = 32; //is fine x is int ubyte b = x; //ok, narrowed x = -1; b = x; //ConvException As for exceptions VS compile-time errors - well, there got to be a reason to use Varaint, namely having dynamic script-like typing. And once there the only way to signal problem is to throw an error, so it is a typical situation in dynamic typing world. -- Dmitry Olshansky
Dec 04 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Dec 04 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Dec 05 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Dec 05 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Dec 05 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, December 06, 2012 01:06:33 Dmitry Olshansky wrote:
 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.
Honestly, the only use cases for Variant that I would consider valid would be those where you _can't_ use static typing in any sane way - the places where you're effectively forced to use a union (where a Variant is a better union). If you can reasonably solve the problem by using a common type, then I'm completely against using Variant for it. Pretty much the only kind of situation that I remember running into where I would consider Variant to be a good solution is one where you literally have to return a type from a function where you can't know that type at compile time, and there is no common type to use. And the only time that I recall running into that recently was in writing a lexer (the values of literals ended up having to be put in a variant type). There are obviously other use cases besides that (database-related stuff and spreadsheets like you mentioned are other possibilities), but they are extremely rare in my experience. In almost all cases, you can and should know the type at compile time, in which case, using Variant makes no sense. - Jonathan M Davis
Dec 05 2012
parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 6 December 2012 at 00:31:53 UTC, Jonathan M Davis 
wrote:

 Pretty much the only kind of situation that I remember running 
 into where I
 would consider Variant to be a good solution is one where you 
 literally have
 to return a type from a function where you can't know that type 
 at compile
 time, and there is no common type to use. And the only time 
 that I recall
 running into that recently was in writing a lexer (the values 
 of literals
 ended up having to be put in a variant type). There are 
 obviously other use
 cases besides that (database-related stuff and spreadsheets 
 like you mentioned
 are other possibilities), but they are extremely rare in my 
 experience. In
 almost all cases, you can and should know the type at compile 
 time, in which
 case, using Variant makes no sense.

 - Jonathan M Davis
My experience with Variant has come from integration in LuaD (Probably like what I'd want from JSON). My main use has been an Algebraic type of string, string[], and string[][string]. (Lua does not have arrays or dictionaries, it has a table). In general when I request data I know which of these it is, however I do have some generic code to operate on any of these types, thus: if(myVar.peek!(string[][string])) ... myVar.get!(string[][string]) Does get repetitive and messy to read. On another note, it is sad I can't have that defined as MyType[MyType].
Dec 10 2012
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 5 December 2012 at 19:32:03 UTC, Jonathan M Davis 
wrote:
 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.
I know for my own project a common type isn't possible (It's a block of raw memory most of the time), but i do know at certain points if it's one type or another just because of where it's at. In order to handle all the types it ends up either being a pointer (union for all) or use long and double and string, but you I have to call them manually (geti, gets, getf). Also implicit conversion only makes sense if it's a type that can be converted to. Any user type can't be converted without alias this or classes/interfaces.
Dec 05 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 05 2012
prev sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Dec 05 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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. :(
Dec 05 2012
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Era Scarecrow:

  So then in theory

  Variant v;
  int i = v.getValue; //calls getValue!int()
I think this is not possible in D. This seems possible: auto i = v.getValue!int; Bye, bearophile
Dec 04 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 4 December 2012 at 12:48:57 UTC, bearophile wrote:
 Era Scarecrow:

 So then in theory

 Variant v;
 int i = v.getValue; //calls getValue!int()
Meant it to be long i, but the idea is the same.
 I think this is not possible in D.

 This seems possible:
 auto i = v.getValue!int;
Indeed... it was just a thought, with that you could remove certain requirements for overriding opCast, and might handle implicit casting... actually that makes sense, allowing for a limited number of types you want it to automatically change to rather than using 'alias this' to subtype it. It also doesn't seem like it would be difficult to add, only 'auto' would cause any real errors (as it's not a known type it can return).
Dec 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-04 13:59, Era Scarecrow wrote:

   It also doesn't seem like it would be difficult to add, only 'auto'
 would cause any real errors (as it's not a known type it can return).
It has been suggested before, overriding on the return type. I has more problems that one might think first. -- /Jacob Carlborg
Dec 04 2012