View mode: basic / threaded / horizontal-split · Log in · Help
May 06, 2012
"R" suffix for reals
"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
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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 07, 2012
Re: "R" suffix for reals
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'.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home