Thanks, this indeed works. One "obvious" (when your program starts to behave weirdly...) down side of this solution: it needs a different dummy for each optional out value of a function, or else multiple variables will be modifying the same dummy.

And, of course, a different dummy for each type of out value, because values after cast() apparently aren't lvalues.

And my last question of my first post: I can't use "auto" for the "out" values right? An enhancement proposal like this would be compatible with D?

Also, the function duplication workaround doesn't works if I templatize the function... Is this inconsistency intentional?


On Saturday, 11 August 2012 at 23:23:48 UTC, Ali Çehreli wrote:
>
> I am not a fan of this solution either. To make the code to compile, define dummy as static:
>
>     static T dummy = T.init;  // <-- this works
>
> That way there will be just one copy for the entire type, instead of one copy per object.
>
> Ali

On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
> And my last question of my first post: I can't use "auto" for the "out" values right? An enhancement proposal like this would be compatible with D?

 I would say.... No. Maybe if it was a union, but I don't think so;.It still needs to know it's type when it's working with, aka statically typed (known at compile-time).

 The auto as an out variable may work in an interpreted or more dynamic language.

On 08/14/2012 06:22 PM, Era Scarecrow wrote:
> On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
>> And my last question of my first post: I can't use "auto" for the
>> "out" values right? An enhancement proposal like this would be
>> compatible with D?
>
> I would say.... No. Maybe if it was a union, but I don't think so;.It
> still needs to know it's type when it's working with, aka statically
> typed (known at compile-time).
>
> The auto as an out variable may work in an interpreted or more dynamic
> language.

Agreed. The function code must be compiled to use certain amount of data from the program stack for that particular parameter. That size of that parameter must be known at compile time.

The compiler could in theory examine the entire program to determine a type for the parameter but the separate compilation model would preclude it.

Ali

On Wednesday, 15 August 2012 at 01:42:11 UTC, Ali Çehreli wrote:
> Agreed. The function code must be compiled to use certain amount of data from the program stack for that particular parameter. That size of that parameter must be known at compile time.
>
> The compiler could in theory examine the entire program to determine a type for the parameter but the separate compilation model would preclude it.

 Although if you used a template you could pull it off... I think... But you'd need the sources for that.

 void multiOut(T)(out T outType) {
   outType = 100;
 }

 int a;
 char b;

 multiOut(a);
 multiOut(b);

 assert(a == 100);
 assert(b == 100);

On Wednesday, 15 August 2012 at 01:22:41 UTC, Era Scarecrow wrote:
> On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
>> And my last question of my first post: I can't use "auto" for the "out" values right? An enhancement proposal like this would be compatible with D?
>
>  I would say.... No. Maybe if it was a union, but I don't think so;.It still needs to know it's type when it's working with, aka statically typed (known at compile-time).
>
>  The auto as an out variable may work in an interpreted or more dynamic language.

It was the reverse way (as in my first post):

bool bar(out ulong output){ output = 0 ; return true;}

auto check = bar(auto num); // error

The type of the out parameter is explicit in this case, but, right now, I need to declarate num outside the function, and thus I can't use the auto keyword.

I'm not sure how this would work for templatized out parameters (if they are permitted)...