Out parameters and initialization

[Unknown W. Brackets]

Except aliases and typedefs (exactly, as I could tell, for the reason of 
consistency) do not use an = sign.  If they did, it would be strange and 
inconsistent.  I am very glad they do not.

Personally, I think = should be disallowed entirely for out parameters, 
and should work on inout parameters in the same way as it does for in 
ones.  This would stay logical.

If out int i = 5 should not compile when no parameter is passed, it 
should not compile when a parameter is passed - as you said.  I think 
the usefulness of global variables, especially considering thread 
safety, would only grow confusing in actual and practical use.

-[Unknown]


> On Sat, 25 Feb 2006 18:58:44 -0800, Unknown W. Brackets 
> <unknown at simplemachines.org> wrote:
>> If that is the meaning, some symbol should be used to indicate that 
>> there is a reference being made.
> 
> The symbols 'inout' and 'out' indicate an alias/reference is being made.
> 
>> I don't think, personally, it makes any sense to say that in is a 
>> replacement for what might be passed.  It is much more like an 
>> initializer, which would never behave in that way.  To me, it is 
>> unclear and unlike the rest of the language to do as you suggest.
> 
> I didn't mean to suggest that 'in' was a replacement for what is passed, 
> but rather that the default initialiser is a replacement for what 
> _isn't_ passed.
> 
>> Your suggestion separates the logic of parameter defaulting from 
>> initialization completely, but they share the same syntax (as they 
>> share again with assignment.)  I think this is, at best, unclear and 
>> clumsy. At worst, it is obviously inconsistent and confusing.
> 
> I think you make a valid point here. default parameters, and assignment 
> (which initialization is essentially) share the same syntax, they both 
> use '='. It does suggest that a default parameter is an initializer, 
> when in fact, I believe it's not that at all. That same syntax, '=', is 
> likely the cause of this thread :)
> 
>> But that is more of a philosophical debate, and that will be for 
>> Walter to answer, ultimately.  My point is that there is a bug here, 
>> nonetheless.
> 
> I agree, my idea at the solution is below.
> 
>> Regardless of what you are saying, why should my initial example 
>> compile? should not compile, it shouldIt should either work as 
>> initialization, or not compile.  It should not compile and do 
>> nothing.  This is also unclear and inconsistent.
> 
> Your first example compiles because you are passing a parameter to all 
> calls of 'test' and therefore the default parameter is never used. 
> However, this for example:
> 
> void test(out uint i = 5)
> {
>     assert(i == 5);
> }
> 
> void main()
> {
>     uint i;
>     test(i); //compiles
>     test();  //cast(uint)5 is not an lvalue
> }
> 
> Will not compile because the default parameter is required for the 2nd 
> call to 'test' and '5' is not an lvalue (cannot be aliased).
> 
> The solution: I think it would be fair to ask for the compiler to error on:
> 
>   void test(out uint i = 5)
> 
> regardless of whether the default parameter is ever required, simply 
> because it will never be legal to have a non lvalue default parameter to 
> an 'out' or 'inout' parameter. At the same time perhaps this should 
> remain valid:
> 
> uint globalVar;
> void test(out uint i = globalVar) {}
> 
> because I can imagine some useful things you can do with this.
> 
> What do you think Walter?
> 
> Regan
> 
>> -[Unknown]