May 07, 2012
On 5/6/2012 7:33 PM, Era Scarecrow wrote:
> Was mostly commenting when I see L, I think 'long' right away, not 'long or
> possibly float/double'.

The L comes from C and meant of "long double".
May 07, 2012
On Monday, 7 May 2012 at 03:42:18 UTC, Walter Bright wrote:
> On 5/6/2012 7:33 PM, Era Scarecrow wrote:
>> Was mostly commenting when I see L, I think 'long' right away, not 'long or
>> possibly float/double'.
>
> The L comes from C and meant of "long double".

 Interesting; But still for me (and likely newbies) if it isn't innately obvious or easy to remember it is something I would forget and never use. Actually I have rarely used floating point to any degree (and when I did it was fairly simple).
May 07, 2012
Walter Bright wrote:

> never encountered a problem with it

Please recall the famous `fori=' vs. `for i=' mistake:

one unintentional changed or added character might change the meening
of the code but compile undetected:
|  auto x = +1L;
|  auto y = -1L;
|  auto z = .1L;

Whereas
|  auto z = .1R;
would need two changes to the intention.

Because of `auto' and `real', which both still aren't in C, D might need to be more picky.

-manfred
May 07, 2012
On Sun, 06 May 2012 21:02:28 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Or maybe you initially have written:
> auto r = 1.1L;
> And later you want to change the number to 1.0 and you fix it like this:
> auto r = 1L;
> Now you have a little bug.

Or maybe you have initially written:

auto d = 1.1;
and later you want to change the number to 1.0 and you fix it like this:

auto d = 1;

Now you have a little bug.

To me the problem of floating pt. vs. integral is orthogonal to the size of the integral/floating point.

-Steve
May 07, 2012
On Monday, 7 May 2012 at 12:34:26 UTC, Steven Schveighoffer wrote:
> On Sun, 06 May 2012 21:02:28 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Or maybe you initially have written:
>> auto r = 1.1L;
>> And later you want to change the number to 1.0 and you fix it like this:
>> auto r = 1L;
>> Now you have a little bug.
>
> Or maybe you have initially written:
>
> auto d = 1.1;
> and later you want to change the number to 1.0 and you fix it like this:
>
> auto d = 1;
>
> Now you have a little bug.
>
> To me the problem of floating pt. vs. integral is orthogonal to the size of the integral/floating point.
>
> -Steve

Since you use the suffix to disambiguate / explicitly specify the type... it is extremely unintuitive if the type suddenly changes while *keeping* the same suffix...

May 07, 2012
On Mon, 07 May 2012 14:11:34 -0400, Arne <arne@linux.nu> wrote:

> On Monday, 7 May 2012 at 12:34:26 UTC, Steven Schveighoffer wrote:
>> On Sun, 06 May 2012 21:02:28 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>>> Or maybe you initially have written:
>>> auto r = 1.1L;
>>> And later you want to change the number to 1.0 and you fix it like this:
>>> auto r = 1L;
>>> Now you have a little bug.
>>
>> Or maybe you have initially written:
>>
>> auto d = 1.1;
>> and later you want to change the number to 1.0 and you fix it like this:
>>
>> auto d = 1;
>>
>> Now you have a little bug.
>>
>> To me the problem of floating pt. vs. integral is orthogonal to the size of the integral/floating point.
>>
>> -Steve
>
> Since you use the suffix to disambiguate / explicitly specify the type... it is extremely unintuitive if the type suddenly changes while *keeping* the same suffix...
>

I concede that is a concern, but really, ".[0-9]" is the suffix that determines it's a floating point, not "L".  I almost think 1f should be an error, it should have to be 1.0f.  Ohhh, I thought of another example:

auto x = 0x1f;

Remove the 0x prefix, and you have:

auto x = 1f; // now a floating point 1 vs. integer 31

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;

-Steve
May 07, 2012
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.
May 07, 2012
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
1 2
Next ›   Last »