## digitalmars.D - "R" suffix for reals

• bearophile (24/24) May 06 2012 "R" suffix for reals
• James Miller (6/30) May 06 2012 I agree with this proposal, phasing out 'L' for reals seems like
• Matej Nanut (4/4) May 06 2012 I didn't know about the decimal-point + L notation for reals. It
• Jonathan M Davis (6/35) May 06 2012 And what is so onerous about having to do 1.0L instead of 1R? 1L is clea...
• bearophile (28/32) May 06 2012 1.0L is always a real in D.
• Mehrdad (2/34) May 06 2012
• Jonathan M Davis (10/50) May 06 2012 I'm sorry, but I think that you're making an issue out of nothing. 1L is...
• Walter Bright (3/11) May 06 2012 I agree. It's as old as C, and I've never encountered a problem with it....
• Era Scarecrow (9/12) May 06 2012 Only if you had to be specific to clarify certain confusion. 95%
• Walter Bright (2/4) May 06 2012 The L comes from C and meant of "long double".
• Era Scarecrow (5/10) May 06 2012 Interesting; But still for me (and likely newbies) if it isn't
• Manfred Nowak (13/14) May 07 2012 Please recall the famous `fori=' vs. `for i=' mistake:
• Era Scarecrow (19/33) May 06 2012 Perhaps it means nothing, but I'll comment anyways.
• Steven Schveighoffer (10/15) May 07 2012 Or maybe you have initially written:
• Arne (4/21) May 07 2012 Since you use the suffix to disambiguate / explicitly specify the
• Steven Schveighoffer (13/40) May 07 2012 I concede that is a concern, but really, ".[0-9]" is the suffix that
• Walter Bright (7/12) May 07 2012 I tend to agree. If you're declaring things with 'auto', then you should...
• Arne (19/36) May 07 2012 Alright, I admit 'auto' is somewhat of a contrived example,
"bearophile" <bearophileHUGS lycos.com> writes:
```"R" suffix for reals

This is small enhancement suggestion :-) (Issue 8049).

The "f" suffix turns a number literal without "." into a float,
while "L" requires a "." in the number literal, otherwise you
have defined a literal of type long:

void main() {
auto x1 = 1f;
static assert(is(typeof(x1) == float));
auto x2 = 1L;
static assert(is(typeof(x2) == long));
auto x3 = 1.0L;
static assert(is(typeof(x3) == real));
}

D has "auto" for local inferencing, so this suffix is able to
cause some problems.

So what do you think about introducing a more specific and less
bug-prone suffix like "R" (eventually using "L" to denote
longs only):

void main() {
auto x = 1R;
static assert(is(typeof(x) == real));
}

Bye,
bearophile
```
May 06 2012
"James Miller" <james aatch.net> writes:
```On Sunday, 6 May 2012 at 22:49:13 UTC, bearophile wrote:
"R" suffix for reals

This is small enhancement suggestion :-) (Issue 8049).

The "f" suffix turns a number literal without "." into a float,
while "L" requires a "." in the number literal, otherwise you
have defined a literal of type long:

void main() {
auto x1 = 1f;
static assert(is(typeof(x1) == float));
auto x2 = 1L;
static assert(is(typeof(x2) == long));
auto x3 = 1.0L;
static assert(is(typeof(x3) == real));
}

D has "auto" for local inferencing, so this suffix is able to
cause some problems.

So what do you think about introducing a more specific and less
bug-prone suffix like "R" (eventually using "L" to denote
longs only):

void main() {
auto x = 1R;
static assert(is(typeof(x) == real));
}

Bye,
bearophile

I agree with this proposal, phasing out 'L' for reals seems like
a good idea, I didn't even know that it was possible until now,
so I imagine it can't be stepping on many people's toes.

--
James Miller
```
May 06 2012
"Matej Nanut" <matejnanut gmail.com> writes:
```I didn't know about the decimal-point + L notation for reals. It
does seem... surprising. I don't see a reason why â€˜Râ€™
wouldn't be a good choice. I also don't see why someone would
write â€˜1.0Lâ€™ and expect a long.
```
May 06 2012
Jonathan M Davis <jmdavisProg gmx.com> writes:
```On Monday, May 07, 2012 00:49:11 bearophile wrote:
"R" suffix for reals

This is small enhancement suggestion :-) (Issue 8049).

The "f" suffix turns a number literal without "." into a float,
while "L" requires a "." in the number literal, otherwise you
have defined a literal of type long:

void main() {
auto x1 = 1f;
static assert(is(typeof(x1) == float));
auto x2 = 1L;
static assert(is(typeof(x2) == long));
auto x3 = 1.0L;
static assert(is(typeof(x3) == real));
}

D has "auto" for local inferencing, so this suffix is able to
cause some problems.

So what do you think about introducing a more specific and less
bug-prone suffix like "R" (eventually using "L" to denote
longs only):

void main() {
auto x = 1R;
static assert(is(typeof(x) == real));
}

And what is so onerous about having to do 1.0L instead of 1R? 1L is clearly a
long, whereas 1.0L is clearly a floating point value (it would have to be
either double or real, and apparently it's real). We _could_ add R, but I
don't really see what it buys us.

- Jonathan M Davis
```
May 06 2012
"bearophile" <bearophileHUGS lycos.com> writes:
```Jonathan M Davis:

And what is so onerous about having to do 1.0L instead of 1R?

It's not onerous, the purpose of "R" is not to save typing ".0".

(it would have to be either double or real, and
apparently it's real).

1.0L is always a real in D.

We _could_ add R, but I don't really see what it buys us.

Octal literals are deprecated in D because programmers sometimes
forget about them, or make mistakes adding a leading zero,
thinking it does nothing as in math, and defining a number
different from the desired one.

If you write "auto x = 1L;" thinking about defining a real, as
you define a float with "auto x = 1F;" you are introducing a
small bug.

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.

The "R" is more symmetric with "f", it works as "f" for real.
This makes learning D a bit simpler.

Very often it's better to have literals as much specific as
possible, otherwise you get situations like the following one,
what's the problem here (Issue 4703)?

import std.stdio: writeln;
void main() {
int[] associative_array = [1:2, 3:4, 5:6];
writeln(associative_array);
}

Bye,
bearophile
```
May 06 2012
"Mehrdad" <wfunction hotmail.com> writes:
```That's why you shouldn't http://www.quickmeme.com/meme/3p5mcu/

On Monday, 7 May 2012 at 01:02:29 UTC, bearophile wrote:
Jonathan M Davis:

And what is so onerous about having to do 1.0L instead of 1R?

It's not onerous, the purpose of "R" is not to save typing ".0".

(it would have to be either double or real, and
apparently it's real).

1.0L is always a real in D.

We _could_ add R, but I don't really see what it buys us.

Octal literals are deprecated in D because programmers
sometimes forget about them, or make mistakes adding a leading
zero, thinking it does nothing as in math, and defining a
number different from the desired one.

If you write "auto x = 1L;" thinking about defining a real, as
you define a float with "auto x = 1F;" you are introducing a
small bug.

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.

The "R" is more symmetric with "f", it works as "f" for real.
This makes learning D a bit simpler.

Very often it's better to have literals as much specific as
possible, otherwise you get situations like the following one,
what's the problem here (Issue 4703)?

import std.stdio: writeln;
void main() {
int[] associative_array = [1:2, 3:4, 5:6];
writeln(associative_array);
}

Bye,
bearophile

```
May 06 2012
Jonathan M Davis <jmdavisProg gmx.com> writes:
```On Monday, May 07, 2012 03:02:28 bearophile wrote:
Jonathan M Davis:
And what is so onerous about having to do 1.0L instead of 1R?

It's not onerous, the purpose of "R" is not to save typing ".0".

(it would have to be either double or real, and
apparently it's real).

1.0L is always a real in D.

We _could_ add R, but I don't really see what it buys us.

Octal literals are deprecated in D because programmers sometimes
forget about them, or make mistakes adding a leading zero,
thinking it does nothing as in math, and defining a number
different from the desired one.

If you write "auto x = 1L;" thinking about defining a real, as
you define a float with "auto x = 1F;" you are introducing a
small bug.

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.

The "R" is more symmetric with "f", it works as "f" for real.
This makes learning D a bit simpler.

Very often it's better to have literals as much specific as
possible, otherwise you get situations like the following one,
what's the problem here (Issue 4703)?

import std.stdio: writeln;
void main() {
int[] associative_array = [1:2, 3:4, 5:6];
writeln(associative_array);
}

I'm sorry, but I think that you're making an issue out of nothing. 1L is
clearly a long, not a real, and you're going to get compilation errors very
quickly if you really meant to have a real. Yes, there _are_ cases where you
could have a silent, logic error, but I really don't think that it's often
enough to merit changing the language. I do not believe that I have _every_
seen this problem in real code. And by introducing R, you would create one
more thing that D programmers would have to learn and know. I don't think that
the suggested change comes even close to justifying itself.

- Jonathan M Davis
```
May 06 2012
Walter Bright <newshound2 digitalmars.com> writes:
```On 5/6/2012 6:46 PM, Jonathan M Davis wrote:
I'm sorry, but I think that you're making an issue out of nothing. 1L is
clearly a long, not a real, and you're going to get compilation errors very
quickly if you really meant to have a real. Yes, there _are_ cases where you
could have a silent, logic error, but I really don't think that it's often
enough to merit changing the language. I do not believe that I have _every_
seen this problem in real code. And by introducing R, you would create one
more thing that D programmers would have to learn and know. I don't think that
the suggested change comes even close to justifying itself.

I agree. It's as old as C, and I've never encountered a problem with it. And as
Era Scarecrow posted, this leads to suffixes for every type.
```
May 06 2012
"Era Scarecrow" <rtcvb32 yahoo.com> writes:
```On Monday, 7 May 2012 at 02:19:19 UTC, Walter Bright wrote:
I agree. It's as old as C, and I've never encountered a problem
with it. And as Era Scarecrow posted, this leads to suffixes
for every type.

Only if you had to be specific to clarify certain confusion. 95%
or more of the time the default would be enough unless you needed
it. Course with auto, unless you want it to default to likely a
double or int (or string), then you'd need to specify or cast it.
More likely it could do more specific valid range testing if
given that information.

Was mostly commenting when I see L, I think 'long' right away,
not 'long or possibly float/double'.
```
May 06 2012
Walter Bright <newshound2 digitalmars.com> writes:
```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 06 2012
"Era Scarecrow" <rtcvb32 yahoo.com> writes:
```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 06 2012
Manfred Nowak <svv1999 hotmail.com> writes:
```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
"Era Scarecrow" <rtcvb32 yahoo.com> writes:
```On Monday, 7 May 2012 at 01:02:29 UTC, bearophile wrote:
Jonathan M Davis:
And what is so onerous about having to do 1.0L instead of 1R?

It's not onerous, the purpose of "R" is not to save typing
".0". If you write "auto x = 1L;" thinking about defining a
real, as  you define a float with "auto x = 1F;" you are
introducing a  small bug.

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.

The "R" is more symmetric with "f", it works as "f" for real.
This makes learning D a bit simpler.

Perhaps it means nothing, but I'll comment anyways.

To me if I were to add suffixes, it would be the first letter of
what made sense, goes with a default type we know. With the
exception of using a-f being hex codes already known.

So...
b - binary
s - short  - likely unneeded
l - long
f - float
r - real
o - octal
h - hexidecimal (or prefix 0x since it's so common and stands
out)

prepend u to any to make unsigned, so ul is unsigned long, ie
10ul. (makes binary safe as ub, but that's kinda ugly)

? - byte
? - int/decimal
d - double (df for double float?)
```
May 06 2012
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
```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
"Arne" <arne linux.nu> writes:
```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
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
```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
Walter Bright <newshound2 digitalmars.com> writes:
```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
"Arne" <arne linux.nu> writes:
```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
```
May 07 2012