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
