View mode: basic / threaded / horizontal-split · Log in · Help
July 04, 2012
Literals starting with 0 will not work with UFCS
0.writeln();
01.writeln();
etc...

Throw up a series of errors while any other number as the leading 
digit seems to work fine. Why is this?
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Wednesday, July 04, 2012 02:20:26 ixid wrote:
> 0.writeln();

This works.

> 01.writeln();

This doesn't.

> etc...
> 
> Throw up a series of errors while any other number as the leading
> digit seems to work fine. Why is this?

It's probably an artifact of getting rid of octal literals and is clearly a 
bug - though you probably shouldn't be starting literals with 0 due to 
possible confusion with octal literals anyway (00 - 07 are permitted because 
they're the same in both octal and decimal, but any other number literal 
starting with 0 is illegal).

The error you get for something like

auto n = 08;

is a bit off too

q.d(5): Error: semicolon expected following auto declaration, not '8'

- Jonathan M Davis
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Tuesday, July 03, 2012 17:34:21 Jonathan M Davis wrote:
> On Wednesday, July 04, 2012 02:20:26 ixid wrote:
> > 0.writeln();
> 
> This works.
> 
> > 01.writeln();
> 
> This doesn't.
> 
> > etc...
> > 
> > Throw up a series of errors while any other number as the leading
> > digit seems to work fine. Why is this?
> 
> It's probably an artifact of getting rid of octal literals and is clearly a
> bug - though you probably shouldn't be starting literals with 0 due to
> possible confusion with octal literals anyway (00 - 07 are permitted because
> they're the same in both octal and decimal, but any other number literal
> starting with 0 is illegal).
> 
> The error you get for something like
> 
> auto n = 08;
> 
> is a bit off too
> 
> q.d(5): Error: semicolon expected following auto declaration, not '8'

Now reported:

http://d.puremagic.com/issues/show_bug.cgi?id=8345
http://d.puremagic.com/issues/show_bug.cgi?id=8346

- Jonathan M Davis
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
> 0.writeln();
>
> This works.

It doesn't with 2.058, are we using different versions? Thanks 
for adding it to the bug list, I am not knowledgeable enough 
about D to judge if something is a bug or if I've just not 
understood it.
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Wednesday, July 04, 2012 03:48:52 ixid wrote:
> > 0.writeln();
> > 
> > This works.
> 
> It doesn't with 2.058, are we using different versions? Thanks
> for adding it to the bug list, I am not knowledgeable enough
> about D to judge if something is a bug or if I've just not
> understood it.

2.059 is the latest release (and is already nearly 3 months old), but I'm 
using the latest from github, so I don't know what 2.059 does.

- Jonathan M Davis
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
I think I'm using 2.059 actually.
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Wednesday, 4 July 2012 at 01:53:40 UTC, Jonathan M Davis wrote:
> On Wednesday, July 04, 2012 03:48:52 ixid wrote:
>> > 0.writeln();
>> > 
>> > This works.
>> 
>> It doesn't with 2.058, are we using different versions? Thanks
>> for adding it to the bug list, I am not knowledgeable enough
>> about D to judge if something is a bug or if I've just not
>> understood it.
>
> 2.059 is the latest release (and is already nearly 3 months 
> old), but I'm
> using the latest from github, so I don't know what 2.059 does.
>
> - Jonathan M Davis

The problem was fixed in 2.060head.
http://d.puremagic.com/issues/show_bug.cgi?id=8252

Kenji Hara
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Wednesday, 4 July 2012 at 00:34:39 UTC, Jonathan M Davis wrote:
> On Wednesday, July 04, 2012 02:20:26 ixid wrote:
>> 0.writeln();
>
> This works.
>
>> 01.writeln();
>
> This doesn't.
>
>> etc...
>> 
>> Throw up a series of errors while any other number as the 
>> leading
>> digit seems to work fine. Why is this?
>
> It's probably an artifact of getting rid of octal literals and 
> is clearly a
> bug - though you probably shouldn't be starting literals with 0 
> due to
> possible confusion with octal literals anyway (00 - 07 are 
> permitted because
> they're the same in both octal and decimal, but any other 
> number literal
> starting with 0 is illegal).
>
> The error you get for something like
>
> auto n = 08;
>
> is a bit off too
>
> q.d(5): Error: semicolon expected following auto declaration, 
> not '8'
>
> - Jonathan M Davis

The one exception I found to starting literals with 0 is when 
using dates - using the DateTime module (excellent write-up, 
btw!) and having to pass dates like 07/04/09 as 7, 4, 9 without 
the leading 0 is kind of awkward, for me at least. Minor gripe.
July 04, 2012
Re: Literals starting with 0 will not work with UFCS
On Thursday, July 05, 2012 01:44:19 Jonathan Andrew wrote:
> The one exception I found to starting literals with 0 is when
> using dates - using the DateTime module (excellent write-up,
> btw!) and having to pass dates like 07/04/09 as 7, 4, 9 without
> the leading 0 is kind of awkward, for me at least. Minor gripe.

Yeah. I ended using leading 0's in that code all over the place without even 
thinking about it, since it's so natural to do with dates, but it works fine as 
long as you don't need 08 or 09. I believe that that's the only place that 
I've really used numeric literals with a leading 0 though. I don't remember 
why 08 and 09 aren't legal though, since they clearly aren't octal literals. 
Oh well, it's a bit annoying, but as you say, it's a minor gripe.

And yay, someone who's actually happy with std.datetime! Actually, several 
people have been quite happy with it, but with all things, it's the complaints 
that people generally bother to voice, and as simple and std.datetime is to 
use, it's a lot to take in. I really need to split it up into separate modules 
so that the documentation is easier to digest, but I'd like something like DIP 
15 or 16 implemented before doing that (which would make it possible to split 
up std.datetime into a std.datetime package with std.datetime.systime, 
std.datetime.date, etc. without breaking code, whereas right now, they have to 
go in a new package). I also need to finish revising the unit tests. So much to 
do...

Oh well, it works great as it is now, and it's good to hear that my article on 
std.datetime helped you understand it. Actually, I think that the questions on 
std.datetime have gone down considerably since I wrote it, so I guess that 
it's doing its job.

- Jonathan M Davis
Top | Discussion index | About this forum | D home