"R" suffix for reals

[Arne]

On Monday, 7 May 2012 at 19:23:03 UTC, Walter Bright wrote:
> On 5/7/2012 12:07 PM, Steven Schveighoffer wrote:
>> However, I think these examples are misleading and do not 
>> prove the point. It
>> shows IMO more that you are better off declaring the type on 
>> the left if your
>> code depends on it always staying the same.
>>
>> i.e. this does not have that problem:
>>
>> real r = 1L;
>
> I tend to agree. If you're declaring things with 'auto', then 
> you should not be relying on a specific type being inferred 
> from the initializer - that would be poor style. Use of auto 
> implies your code is more generic and adaptable to whatever 
> type the initializer turns out to be.
>
> If your usage of r requires it to be a specific type, it should 
> be declared as having that type.

Alright, I admit 'auto' is somewhat of a contrived example,
my main concern is with 'function overloading'/'template type
inference'/when creating 'compound/complex types'.

I think we have a general issue with concise definitions of
literals...
    1. ambiguous suffixes
    2. manu's __vector()
    3. dynamic vs static array literals: auto[$] ?
    any other similar issues?

What is the main reason we don't allow... something like:
    sqrt(real(3));
... does it result in any parsing ambiguities?

I'm hoping for a consistent solution to all of the above
issues... be it... suffix or function style initializer... or
<insert any other idea>... as long as it solves all the above
'literal issues' in a consistent way...

Thanks for listening :)
Arne