Some thoughts about C and D, return data through parameters

[Steven Schveighoffer]

On 12/19/17 9:35 AM, ketmar wrote:
> Steven Schveighoffer wrote:
> 
>> I insist that auto is a storage qualifier
> 
> what is the rationale to have `auto` as storage qualifier? except of 
> keeping it in line with the ancient C feature (and most C programmers 
> don't even know what `auto` does in C).

Because it's consistent. D says that types are inferred when the type is 
missing and there is a storage class specified. Making auto a storage 
class fits this definitely perfectly.

> 
> i bet that most people are sure that `auto` in D is a type placeholder. 
> it works like type placeholder, it looks like type placeholder, why 
> don't make it a type placeholder?

It could be specified that way, but then it's another thing to explain, 
which doesn't add any value. The spec can read "The type of a variable 
is inferred from the initializer if you specify a storage class" or it 
can read "The type of a variable is inferred from the initializer if you 
specify a storage class, or if you use 'auto' as the type placeholder." 
I don't see a gain there.

> ok, i can see *one* place where it won't be consistent: `foo (auto ref 
> Type v)`. which can be left as a logical exception ('cmon, `enum a = 
> 20;`) is not declaring an enum too, it is used to declare "inline 
> constant".

auto ref, while a nice feature, is a horrible syntax. It's an exception 
no matter what we do!

> 
> also:
> 
>      auto int n = 42;
> 
> yay: "Error: variable n storage class 'auto' has no effect if type is 
> not inferred, did you mean 'scope'?" >
> even D compiler knows that `auto` is used as *type* *placeholder*. 
> 'cmon, let's promote it to actual type placeholder!

Another inconsistency that should be fixed (and allowed).

-Steve