bearophile <bearophileHUGS lycos.com> writes:

This comes from a small sub-thread in D.learn (but I have asked for it the
first time in bug 3837 time ago):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030

I suggest to turn floating point literals like the following into syntax errors
(maybe just deprecated, so they get accepted using the -d compiler switch),
because the saving of one digit is not worth the small troubles they cause now
and then:

.5
3.

And require to write them like this:

0.5
3.0

The enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=6277

(Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too) but I
think this is a special case).

(I think disallowing 3. is also useful if you want to allow the introduction of
the .. or ... interval syntax. The trailing FP dot causes some troubles and
asks for an extra space).

What do you think?

If I see enough people against this idea I will probably close the enhancement
request.

Bye,
bearophile

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iva982$dm8$1 digitalmars.com...
 This comes from a small sub-thread in D.learn (but I have asked for it the 
 first time in bug 3837 time ago):
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030

 I suggest to turn floating point literals like the following into syntax 
 errors (maybe just deprecated, so they get accepted using the -d compiler 
 switch), because the saving of one digit is not worth the small troubles 
 they cause now and then:

 .5
 3.

 And require to write them like this:

 0.5
 3.0

 The enhancement request:
 http://d.puremagic.com/issues/show_bug.cgi?id=6277

 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too) 
 but I think this is a special case).

 (I think disallowing 3. is also useful if you want to allow the 
 introduction of the .. or ... interval syntax. The trailing FP dot causes 
 some troubles and asks for an extra space).

 What do you think?

 If I see enough people against this idea I will probably close the 
 enhancement request.

I see zero benefit to the 1., .1 feature and it's been a problem in syntax 
discussions in the past. I'm completely in favor of ditching it, and have 
already put in a bugzilla vote for bearophile's enhancement request.

Timon Gehr <timon.gehr gmx.ch> writes:

Nick Sabalausky wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:iva982$dm8$1 digitalmars.com...
 This comes from a small sub-thread in D.learn (but I have asked for it the
 first time in bug 3837 time ago):


http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030
 I suggest to turn floating point literals like the following into syntax
 errors (maybe just deprecated, so they get accepted using the -d compiler
 switch), because the saving of one digit is not worth the small troubles
 they cause now and then:

 .5
 3.

 And require to write them like this:

 0.5
 3.0

 The enhancement request:
 http://d.puremagic.com/issues/show_bug.cgi?id=6277

 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too)
 but I think this is a special case).

 (I think disallowing 3. is also useful if you want to allow the
 introduction of the .. or ... interval syntax. The trailing FP dot causes
 some troubles and asks for an extra space).

 What do you think?

 If I see enough people against this idea I will probably close the
 enhancement request.

 I see zero benefit to the 1., .1 feature and it's been a problem in syntax
 discussions in the past. I'm completely in favor of ditching it, and have
 already put in a bugzilla vote for bearophile's enhancement request.

+1. Another benefit of ditching it is neater UFCS (if it ever gets implemented):

4.foo(bar);

Cheers,
-Timon

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

+1, I just had a bug yesterday where I erroneously used .1 instead of
1. . And I introduced that bug while fixing another one, heh.

Jacob Carlborg <doob me.com> writes:

On 2011-07-09 21:28, Timon Gehr wrote:
 Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:iva982$dm8$1 digitalmars.com...
 This comes from a small sub-thread in D.learn (but I have asked for it the
 first time in bug 3837 time ago):


 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030
 I suggest to turn floating point literals like the following into syntax
 errors (maybe just deprecated, so they get accepted using the -d compiler
 switch), because the saving of one digit is not worth the small troubles
 they cause now and then:

 .5
 3.

 And require to write them like this:

 0.5
 3.0

 The enhancement request:
 http://d.puremagic.com/issues/show_bug.cgi?id=6277

 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too)
 but I think this is a special case).

 (I think disallowing 3. is also useful if you want to allow the
 introduction of the .. or ... interval syntax. The trailing FP dot causes
 some troubles and asks for an extra space).

 What do you think?

 If I see enough people against this idea I will probably close the
 enhancement request.

 I see zero benefit to the 1., .1 feature and it's been a problem in syntax
 discussions in the past. I'm completely in favor of ditching it, and have
 already put in a bugzilla vote for bearophile's enhancement request.

 +1. Another benefit of ditching it is neater UFCS (if it ever gets
implemented):

 4.foo(bar);

 Cheers,
 -Timon

Agree. 1.f will conflict with UFCS.

-- 
/Jacob Carlborg

Daniel Gibson <metalcaedes gmail.com> writes:

Am 09.07.2011 21:13, schrieb bearophile:
 This comes from a small sub-thread in D.learn (but I have asked for it the
first time in bug 3837 time ago):
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030
 
 I suggest to turn floating point literals like the following into syntax
errors (maybe just deprecated, so they get accepted using the -d compiler
switch), because the saving of one digit is not worth the small troubles they
cause now and then:
 
 .5
 3.
 
 And require to write them like this:
 
 0.5
 3.0
 
 The enhancement request:
 http://d.puremagic.com/issues/show_bug.cgi?id=6277
 
 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too) but I
think this is a special case).
 
 (I think disallowing 3. is also useful if you want to allow the introduction
of the .. or ... interval syntax. The trailing FP dot causes some troubles and
asks for an extra space).
 
 What do you think?
 
 If I see enough people against this idea I will probably close the enhancement
request.
 
 Bye,
 bearophile

I voted for it.
And I don't think the special cases 1.f and 1.L are needed, but would
impair consistency (typing 1.0f is just one additional character, so why
bother...)

Cheers,
- Daniel

Bernard Helyer <b.helyer gmail.com> writes:

I agree with you, they cause far more pain than they are worth. Axe 'em!

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Sat, 09 Jul 2011 21:13:06 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

[Good stuff]

Votes += 1.0;

-- 
   Simen

Jacob Carlborg <doob me.com> writes:

On 2011-07-09 21:13, bearophile wrote:
 This comes from a small sub-thread in D.learn (but I have asked for it the
first time in bug 3837 time ago):
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030

 I suggest to turn floating point literals like the following into syntax
errors (maybe just deprecated, so they get accepted using the -d compiler
switch), because the saving of one digit is not worth the small troubles they
cause now and then:

 .5
 3.

 And require to write them like this:

 0.5
 3.0

 The enhancement request:
 http://d.puremagic.com/issues/show_bug.cgi?id=6277

 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too) but I
think this is a special case).

 (I think disallowing 3. is also useful if you want to allow the introduction
of the .. or ... interval syntax. The trailing FP dot causes some troubles and
asks for an extra space).

 What do you think?

 If I see enough people against this idea I will probably close the enhancement
request.

 Bye,
 bearophile

Please kill this syntax. I don't think 1.f should be allowed. It would 
still be a problem with UFCS, if we ever get that.

-- 
/Jacob Carlborg

"Alex_Dovhal" <alex_dovhal yahoo.com> writes:

"bearophile" <bearophileHUGS lycos.com> wrote:
[...]

+1.0 vote.
Also, no one writes .5 or 3.  on paper to save one char. 

bearophile <bearophileHUGS lycos.com> writes:

So far 8 people beside me have answered with a positive vote (Alex Dovhal,
Andrej Mitrovic, Bernard Helyer, Daniel Gibson, Jacob Carlborg, Nick
Sabalausky, Simen Kjaeraas, Timon Gehr) and so far no one has voted against it.

Currently the enhancement request in Bugzilla has 7 votes (cbkbbejeap,
metalcaedes, timon.gehr, brian-schott, doob, mike-wey, josvanuden).

I'd like to know what Don thinks about this because he knows floating point
matters well, but he will be absent for few more days.

I'd like to know what Andrei and Walter think about this small breaking change.
Walter is currently busy with the beta of 2.054, but maybe he is able to find
the bit of time to comment.

Jacob Carlborg reminds that 1.f conflicts with the UFCS, I think the suggestion
by Daniel Murphy of the special case is not worth it.

If this idea gets accepted then I think it's worth changing the other direction
too, I mean the default printing of a floating point value with no decimal part:


import std.stdio;
void main() {
    double x = 3.0;
    writeln(x);
}


Currently (2.054beta3. I'd like beta releases to show a progressive beta number
too) this prints:

3

Python here prints 3.0 and I think D is better to do the same, especially if
the leading zero becomes required for the FP literals.

Bye,
bearophile

"Daniel Murphy" <yebblies nospamgmail.com> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ivcg7j$ooj$1 digitalmars.com...
 Jacob Carlborg reminds that 1.f conflicts with the UFCS, I think the 
 suggestion by Daniel Murphy of the special case is not worth it.

If the only reason for removing 1.f and 1.L is to aid ufcs we should also 
get rid of leading underscores after the decimal point.  eg 1._3 also 
conflicts with ufcs.  And don't forget hex floating point literals. 

bearophile <bearophileHUGS lycos.com> writes:

Daniel Murphy:

 If the only reason for removing 1.f and 1.L is to aid ufcs

It's not the only reason, it's also a special case of the rule that asks for a
zero.


 we should also get rid of leading underscores after the decimal
 point.  eg 1._3 also conflicts with ufcs.

I see (this doesn't look nice regardless of UFCS, but changing it introduces a
special case in the use of the underscore).


 And don't forget hex floating point literals.

Right.

Bye,
bearophile

Timon Gehr <timon.gehr gmx.ch> writes:

bearophile wrote:
 Daniel Murphy:

 If the only reason for removing 1.f and 1.L is to aid ufcs

 It's not the only reason, it's also a special case of the rule that asks for a
zero.


 we should also get rid of leading underscores after the decimal
 point.  eg 1._3 also conflicts with ufcs.

 I see (this doesn't look nice regardless of UFCS, but changing it introduces a

special case in the use of the underscore).
 [snip.]

This is not a particularly strong argument in this case. Numeric literals cannot
*start* with an underscore either. For a similar reason. You add some detail to
the exception to the usage of the underscore, you do not really introduce a new
one. ;)

Related: ._1

(Btw: the lexer has to do some check when it encounters '.' within a number
anyways. Currently, this is checking if the following character is not '.'
The change would turn it into checking if the following character is numeric.)

Cheers,
-Timon

bearophile <bearophileHUGS lycos.com> writes:

Timon Gehr:

 This is not a particularly strong argument in this case. Numeric literals
cannot
 *start* with an underscore either. For a similar reason. You add some detail to
 the exception to the usage of the underscore, you do not really introduce a new
 one. ;)

OK.

Bye,
bearophile

KennyTM~ <kennytm gmail.com> writes:

On Jul 11, 11 02:03, bearophile wrote:
 Daniel Murphy:

 If the only reason for removing 1.f and 1.L is to aid ufcs

 It's not the only reason, it's also a special case of the rule that asks for a
zero.


 we should also get rid of leading underscores after the decimal
 point.  eg 1._3 also conflicts with ufcs.

 I see (this doesn't look nice regardless of UFCS, but changing it introduces a
special case in the use of the underscore).

No special case needed. Just complicate the grammar to

     // in terms of regex: [0-9][0-9_]*

     DecimalDigits:
        DecimalDigit
        DecimalDigit DecimalDigitsOrUnderscores

     DecimalDigitsOrUnderscores:
        DecimalDigitOrUnderscore
        DecimalDigitOrUnderscore DecimalDigitsOrUnderscores

     DecimalDigit:
        0
        NonZeroDigit

     DecimalDigitOrUnderscore
        _
        DecimalDigit

(similar for HexDigits)

is enough to get rid of leading underscores. (See also 
http://d.puremagic.com/issues/show_bug.cgi?id=2734) But I'd prefer 
keeping the grammar simple and require the programmer to add '(' ')'

     (1)._1;
     (4)._0f;
     (0xf).deep-2;

or a space ' '

     1 ._1;
     4 ._0f;
     0xf .deep-2;

if they really meant to.

 And don't forget hex floating point literals.

 Right.

 Bye,
 bearophile

Timon Gehr <timon.gehr gmx.ch> writes:

KennyTM~ wrote:
 No special case needed. Just complicate the grammar to

     // in terms of regex: [0-9][0-9_]*

     DecimalDigits:
        DecimalDigit
        DecimalDigit DecimalDigitsOrUnderscores

     DecimalDigitsOrUnderscores:
        DecimalDigitOrUnderscore
        DecimalDigitOrUnderscore DecimalDigitsOrUnderscores

     DecimalDigit:
        0
        NonZeroDigit

     DecimalDigitOrUnderscore
        _
        DecimalDigit

 (similar for HexDigits)

I don't get what you are saying here.

The change turns this:
DecimalFloat:
  LeadingDecimal .
  LeadingDecimal . DecimalDigits
  DecimalDigits . DecimalDigits DecimalExponent
  . Decimal
  . Decimal DecimalExponent
  LeadingDecimal DecimalExponent

into this:
DecimalFloat:
  LeadingDecimal . LeadingDecimal
  DecimalDigits . LeadingDecimal DecimalExponent
  LeadingDecimal DecimalExponent

(similarly for hex)

That is making the grammar *simpler* in my book.

 is enough to get rid of leading underscores. (See also
 http://d.puremagic.com/issues/show_bug.cgi?id=2734) But I'd prefer
 keeping the grammar simple and require the programmer to add '(' ')'

      (1)._1;
      (4)._0f;
      (0xf).deep-2;

 or a space ' '

      1 ._1;
      4 ._0f;
      0xf .deep-2;

 if they really meant to.

That is quite ugly.

Cheers,
-Timon

Caligo <iteronvexor gmail.com> writes:

while we are at it, let's get rid of this too:

class _{ }

why would anyone want to name a class or a variable _ ??

bearophile <bearophileHUGS lycos.com> writes:

Caligo:

 while we are at it, let's get rid of this too:
 
 class _{ }
 
 why would anyone want to name a class or a variable _ ??

I use _ now and then in debugging as variable name when I don't care for the
name itself (but this is not a very good practice otherwise).
While in the years "incomplete"  floating point literals have caused me some
small troubles, a _ class/struct/union name has caused me none of them, so I
suggest to not change this.

Bye,
bearophile

Caligo <iteronvexor gmail.com> writes:

It would be really great if we could put all the breaking changes into
one release to minimize disruption.  iirc, another breaking change is
the fix to foreach.

bearophile <bearophileHUGS lycos.com> writes:

Caligo:

 It would be really great if we could put all the breaking changes into
 one release to minimize disruption.  iirc, another breaking change is
 the fix to foreach.

Walter has not commented on both of them, so this discussion is just
theoretical still.

DMD 2.054 will introduce several small changes, in switch, OOP, etc. From my
experience here I've seen that even simple things need some thinking time, so I
think you can't put them all in a single release. There are just too many rough
corners to fix in D. I have a list (all of them are in Bugzilla already), I'd
like things to go on faster, but I think they need their time.

Bye,
bearophile

Chris Molozian <chris cmoz.me> writes:

Maybe they want to write an API with a "Web 2.0" style 
<http://documentcloud.github.com/underscore/>? :-P

Chris


On 07/11/11 00:49, Caligo wrote:
 while we are at it, let's get rid of this too:

 class _{ }

 why would anyone want to name a class or a variable _ ??

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 7/11/11, Caligo <iteronvexor gmail.com> wrote:
 while we are at it, let's get rid of this too:

 class _{ }

 why would anyone want to name a class or a variable _ ??

I think his is used in dranges, to make it do stuff like:
map!(_1 + _2)(bar);

Something like that.. not sure.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Sun, 10 Jul 2011 19:51:10 +0200, Daniel Murphy  
<yebblies nospamgmail.com> wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:ivcg7j$ooj$1 digitalmars.com...
 Jacob Carlborg reminds that 1.f conflicts with the UFCS, I think the
 suggestion by Daniel Murphy of the special case is not worth it.

 If the only reason for removing 1.f and 1.L is to aid ufcs we should also
 get rid of leading underscores after the decimal point.  eg 1._3 also
 conflicts with ufcs.  And don't forget hex floating point literals.

Now if f and L were functions taking an int as their first parameter,
they could be defined thusly:

 ufcs  property
float f(int n) {
     return n;
}

 ufcs  property
double L(long n) {
     return n;
}

Furthermore, magic could be added:

 ufcs  property
auto opDispatch(string name)(int n) if (isValidHexString(name)) {
     static if (too many digits for real) {
         return BigFloat(to!string(n) ~ "." ~ name);
     } else {
         // convert to real and return
     }
}


See? Marvellous! :p
-- 
   Simen

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sun, 10 Jul 2011 13:51:10 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:ivcg7j$ooj$1 digitalmars.com...
 Jacob Carlborg reminds that 1.f conflicts with the UFCS, I think the
 suggestion by Daniel Murphy of the special case is not worth it.

 If the only reason for removing 1.f and 1.L is to aid ufcs we should also
 get rid of leading underscores after the decimal point.  eg 1._3 also
 conflicts with ufcs.

I can see no possible use case for 1._3

The _ is typically used to indicate a separator, the decimal place already  
is one.

So yeah, get rid of that too.

-Steve

Trass3r <un known.com> writes:

 .5
 3.

 And require to write them like this:

 0.5
 3.0

+1

 (Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too)  
 but I think this is a special case).

-1

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

bearophile Wrote:

 This comes from a small sub-thread in D.learn (but I have asked for it the
first time in bug 3837 time ago):
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030
 
 I suggest to turn floating point literals like the following into syntax
errors (maybe just deprecated, so they get accepted using the -d compiler
switch), because the saving of one digit is not worth the small troubles they
cause now and then:
 
 .5
 3.
 
 And require to write them like this:
 
 0.5
 3.0
 

As I slowly approach release of a D version of the General Decimal Arithmetic
specification:

I agree that this syntax (1. or .1) should not be permitted, but it is called
out in the GDA specification.

I don't have any problem with not including it. It only arises in converting
from a string to a decimal number, i.e. Decimal(".1"), Decimal("1.").

Conversion from real numbers or integers is based on what the compiler accepts,
so Decimal(1_000_000) is accepted even though it isn't allowed in the GDA
specification. There's really no way to force the compiler not to allow it.

This is just a heads up. I'll modify the code to disallow 1. and .1 strings. If
anyone has an objection let me know.

It's a relatively small change for me to make, much simpler than a change to
the compiler.

Paul