Automatic typing

John Colvin john.loughran.colvin at gmail.com
Fri Jun 28 18:57:17 PDT 2013


On Saturday, 29 June 2013 at 01:49:01 UTC, JS wrote:
> On Saturday, 29 June 2013 at 01:31:13 UTC, Walter Bright wrote:
>> On 6/28/2013 5:00 PM, JS wrote:
>>> Is variant useful? If not then you have a point. I'm not 
>>> proposing anything that
>>> variant can't already do except add compile time performance. 
>>> I do not think the
>>> complexity is much more than what is already done.
>>>
>>> D already checks for time mismatch. With such a variant or 
>>> auto the check simply
>>> is more intelligent.
>>>
>>> e.g.,
>>>
>>> auto x;  // x's type is undefined or possibly variant.
>>> x = 3;   // x's type is set temporarily to an int
>>> ...
>>> x = 3.0; // ****
>>>
>>>
>>> at **** we have several possibilities.
>>>
>>>   1. Throw an error, this makes auto more useful and avoids 
>>> many pitfalls.
>>>   2. Set x's type to a variant. [possibly goto 3 if castable 
>>> to new type]
>>>   3. Set x's type to a double.
>>>
>>> Both 2 and 3 require an extra pass to convert the code 
>>> because it uses forward
>>> inference.
>>>
>>> auto looks only at the immediate assignment expression to 
>>> determine the type. I
>>> am talking about generalizing it to look in the scope with 
>>> possible fallback to
>>> a variant type with optional warning, an error, or type 
>>> enlargement.
>>
>>
>> Again, I need a compelling use case. It's not enough to say 
>> it's the same as variant, and it's not enough to say it can be 
>> implemented.
>>
>> A compelling use case would be a pattern that is commonplace, 
>> and for which the workarounds are ugly, unsafe, error prone, 
>> unportable, etc.
>
> What was the use case for auto that got in into the language?

A quick look at any heavily templated c++ (pre c++11) is all you 
need to justify it.
auto cuts code clutter by huge amounts all over the place.


More information about the Digitalmars-d mailing list