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