digitalmars.D - Re: Re: Is the world coming to an end?

--20cf302d4d18200454049ff70741
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

 0b and 0x are not "dangerous" so there's no need to remove/deprecate them  
 and


 thus cause breakage of code using them.


 At least 0x is quite common (certainly more common than octal numbers) so  
 it


 makes sense to have this short syntax (IMHO).



As I wrote, I think it's great that 010 != 8 anymore.

I just think that 0o10 would be more consistent with 0x and 0b. Obviously  
the framework is there for parsing the literals, and AFAIK, 0o isn't  
accepted today so no code would be broken.

011 = 11
0b11 = 3
0x11 = 17
0o11 = 9

is much more consistent than

011 = 11
0b11 = 3
0x11 = 17
octal!11 = 9

A D-newbie would probably be able to guess 0o for octal, but hardly octal!.  
octal! breaks the rule of least surprise.

In any case, everything is better than 011 = 9

--20cf302d4d18200454049ff70741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

&gt; 0b and 0x are not &quot;dangerous&quot; so there&#39;s no need to remo=
ve/deprecate them and<br />&gt; <br />&gt; thus cause breakage of code usin=
g them.<br />&gt; <br />&gt; At least 0x is quite common (certainly more co=
mmon than octal numbers) so it<br />&gt; <br />&gt; makes sense to have thi=
s short syntax (IMHO).<br />&gt; <br /><br />As I wrote, I think it&#39;s g=
reat that 010 !=3D 8 anymore.<br /><br />I just think that 0o10 would be mo=
re consistent with 0x and 0b. Obviously the framework is there for parsing =
the literals, and AFAIK, 0o isn&#39;t accepted today so no code would be br=
oken.<br /><br />011 =3D 11<br />0b11 =3D 3<br />0x11 =3D 17<br />0o11 =3D =
9<br /><br />is much more consistent than<br /><br />011 =3D 11<br />0b11 =
=3D 3<br />0x11 =3D 17<br />octal!11 =3D 9<br /><br />A D-newbie would prob=
ably be able to guess 0o for octal, but hardly octal!. octal! breaks the ru=
le of least surprise.<br /><br />In any case, everything is better than 011=
 =3D 9
--20cf302d4d18200454049ff70741--

Apr 02 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


Except a big error

     octal literals 011 are deprecated, use std.conv.octal!11 instead

will be emitted when the said newbie tries to compile with 011 :). See 
commit 
https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932

Apr 02 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 06:49, KennyTM~ wrote:
 On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 Except a big error

 octal literals 011 are deprecated, use std.conv.octal!11 instead

 will be emitted when the said newbie tries to compile with 011 :). See
 commit
 https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932


But of course

  1. this message is specific to the dmd front-end. Other lexers might
     not show this message
  2. this assumes std.conv.octal exists, though it may not be the case
     (e.g. using Tango without Phobos (well Tango devs could add just
     std.conv.octal)).

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 00:58, schrieb KennyTM~:
 On Apr 3, 11 06:49, KennyTM~ wrote:
 On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 Except a big error

 octal literals 011 are deprecated, use std.conv.octal!11 instead

 will be emitted when the said newbie tries to compile with 011 :). See
 commit
 https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932


 But of course
 
  1. this message is specific to the dmd front-end. Other lexers might
     not show this message
  2. this assumes std.conv.octal exists, though it may not be the case
     (e.g. using Tango without Phobos (well Tango devs could add just
     std.conv.octal)).


If Tango is ever ported to D2 it should be possible to use Phobos and Tango at
the same time (thanks to druntime), so that shouldn't be an issue, right?

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 3:58 PM, KennyTM~ wrote:
 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


Appropriate and informative error messages are properly 
quality-of-implementation issues. As the dmd source shows, doing this message
is 
trivial.

 2. this assumes std.conv.octal exists, though it may not be the case
 (e.g. using Tango without Phobos (well Tango devs could add just
 std.conv.octal)).


This change will not migrate to D1.

Apr 02 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 07:52, Walter Bright wrote:
 On 4/2/2011 3:58 PM, KennyTM~ wrote:
 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


 Appropriate and informative error messages are properly
 quality-of-implementation issues. As the dmd source shows, doing this
 message is trivial.


DMD recognizes the octal literal then rejects it later. Ideally the 
lexer should not accept 0\d{2,} at all.

 2. this assumes std.conv.octal exists, though it may not be the case
 (e.g. using Tango without Phobos (well Tango devs could add just
 std.conv.octal)).


 This change will not migrate to D1.


Yes. I mean Tango for D2 (if it will be finished?)

Anyway the above aren't really big problems. I don't expect newbies know 
octal literals :).

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 5:34 PM, KennyTM~ wrote:
 On Apr 3, 11 07:52, Walter Bright wrote:
 On 4/2/2011 3:58 PM, KennyTM~ wrote:
 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


 Appropriate and informative error messages are properly
 quality-of-implementation issues. As the dmd source shows, doing this
 message is trivial.


 DMD recognizes the octal literal then rejects it later. Ideally the lexer
should
 not accept 0\d{2,} at all.


That's for backwards compatibility.

 Yes. I mean Tango for D2 (if it will be finished?)


I hope that Tango for D2 will not have gratuitous incompatibilities.

Apr 02 2011

Michel Fortin <michel.fortin michelf.com> writes:

On 2011-04-02 18:27:12 -0400, ulrik.mikaelsson gmail.com said:

 011 = 11
 0b11 = 3
 0x11 = 17
 0o11 = 9
 
 is much more consistent than
 
 011 = 11
 0b11 = 3
 0x11 = 17
 octal!11 = 9


I too would prefer 0o11 for consistency.

It's funny that D (the language) has binary notation built-in (which C 
doesn't have) but no octal notation anymore (which C has). You now have 
to resort to a library template for that, and it doesn't work for big 
numbers: try assert(octal!1777777777777777777777 == 
0xFFFF_FFFF_FFFF_FFFF). Not that I expect anyone to want to write big 
64-bit numbers in octal, but it makes the new "official" octal notation 
more like a hack.

But it's a good thing that the old error-prone octal notation is 
deprecated. So overall I think the change is positive, I just find the 
replacement a little too hackish.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 4:11 PM, Michel Fortin wrote:
 It's funny that D (the language) has binary notation built-in (which C doesn't
 have) but no octal notation anymore (which C has).


The problem with the octal literals is, as has been often complained about, 
people getting surprised by it. I've never heard of anyone being surprised by 
the binary or hex literals.

 You now have to resort to a
 library template for that,


I think it's a feature, not a "resort", that library templates can do this
well. 
I think it's far better than C++0x's user defined literals, for example.

 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not that I
expect
 anyone to want to write big 64-bit numbers in octal, but it makes the new
 "official" octal notation more like a hack.


If you use octal!"1777777777777777777777" it will work correctly. You're right 
in that the decimal literal being "converted" to octal is a bit of a hack.

The octal!1777777777777777777777 will fail at compile time with an integer 
overflow, it never gets to the runtime assert.

Apr 02 2011

Adam D. Ruppe <destructionator gmail.com> writes:

Walter Bright wrote:
 You're right in that the decimal literal being "converted"
 to octal is a bit of a hack.


Yeah, but it's a no-win scenario.

Without it, people would bitch and moan that they have to put
quotes around little numbers like permission masks.

With it, people bitch and moan that its a hack, probably without
ever actually using it.

Apr 02 2011

Michel Fortin <michel.fortin michelf.com> writes:

On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> said:

 On 4/2/2011 4:11 PM, Michel Fortin wrote:
 It's funny that D (the language) has binary notation built-in (which C doesn't
 have) but no octal notation anymore (which C has).


 The problem with the octal literals is, as has been often complained 
 about, people getting surprised by it. I've never heard of anyone being 
 surprised by the binary or hex literals.


Indeed. Isn't that a good argument for implementing octal literals the 
same way as binary and hex literals?


 You now have to resort to a
 library template for that,


 I think it's a feature, not a "resort", that library templates can do 
 this well. I think it's far better than C++0x's user defined literals, 
 for example.


I disagree that it's better. With C++ user defined literals the user 
doesn't have to find by himself whether the number fits within the 
range of a regular integer literal and if not fall back to using a 
string as the template argument instead.

I don't think it's much worse, but I fail to see how it could be better.


 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not that 
 I expect
 anyone to want to write big 64-bit numbers in octal, but it makes the new
 "official" octal notation more like a hack.


 If you use octal!"1777777777777777777777" it will work correctly. 
 You're right in that the decimal literal being "converted" to octal is 
 a bit of a hack.
 
 The octal!1777777777777777777777 will fail at compile time with an 
 integer overflow, it never gets to the runtime assert.


Which makes me wonder, what does the compiler suggests in the error 
message when it encounters 01777777777777777777777 ? I suspect it 
doesn't add the necessary quotes, does it?

The new syntax is certainly usable, it's just inelegant and hackish. 
Its your language, it's your choice, and I'll admit it won't affect me 
much.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Apr 02 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 08:30, Michel Fortin wrote:
 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com>
 said:

 On 4/2/2011 4:11 PM, Michel Fortin wrote:
 It's funny that D (the language) has binary notation built-in (which
 C doesn't
 have) but no octal notation anymore (which C has).


 The problem with the octal literals is, as has been often complained
 about, people getting surprised by it. I've never heard of anyone
 being surprised by the binary or hex literals.


 Indeed. Isn't that a good argument for implementing octal literals the
 same way as binary and hex literals?


 You now have to resort to a
 library template for that,


 I think it's a feature, not a "resort", that library templates can do
 this well. I think it's far better than C++0x's user defined literals,
 for example.


 I disagree that it's better. With C++ user defined literals the user
 doesn't have to find by himself whether the number fits within the range
 of a regular integer literal and if not fall back to using a string as
 the template argument instead.


This is a problem but as I'd test it's a non-issue. Running a Google 
code search on   [^.'"-]\b0[0-7]{7,}[ulUL]*\b -0{8,}   shows only two 
instances of real (i.e. not used for testing the format function) usage 
of long (> 7 digits) octal literals in the first few pages:

     037777600000l  in Android's OpenSSL (this is 0xffff_0000L)
     077777777777L  in Apache's ASF (this is 0x1_ffff_ffffL)

Both of them fit inside 2^^63 as decimal digits for octal!(), and both 
of them could better be represented as hex if ported.

 I don't think it's much worse, but I fail to see how it could be better.


Avoiding needing to create another kind of literal?

 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not
 that I expect
 anyone to want to write big 64-bit numbers in octal, but it makes the
 new
 "official" octal notation more like a hack.


 If you use octal!"1777777777777777777777" it will work correctly.
 You're right in that the decimal literal being "converted" to octal is
 a bit of a hack.

 The octal!1777777777777777777777 will fail at compile time with an
 integer overflow, it never gets to the runtime assert.


 Which makes me wonder, what does the compiler suggests in the error
 message when it encounters 01777777777777777777777 ? I suspect it
 doesn't add the necessary quotes, does it?


There's no quotes, and there should be, but the extra cost for this 
branch may not worth it (the lower limit of quotes depends on whether it 
is a long/unsigned literal).

 The new syntax is certainly usable, it's just inelegant and hackish. Its
 your language, it's your choice, and I'll admit it won't affect me much.

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 5:30 PM, Michel Fortin wrote:
 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> said:
 The problem with the octal literals is, as has been often complained about,
 people getting surprised by it. I've never heard of anyone being surprised by
 the binary or hex literals.


 as binary and hex literals?


Yes, except for something else - the rarity of need for octal literals. The
only 
modern usage I've seen of it is for file permissions.


 I think it's a feature, not a "resort", that library templates can do this
 well. I think it's far better than C++0x's user defined literals, for example.


 have to find by himself whether the number fits within the range of a regular
 integer literal and if not fall back to using a string as the template argument
 instead.


I believe that if you attempted to do octal literals using C++0x user defined 
literals, you'd run into exactly the same issue (overflow). See:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf

C++0x user defined literals call a global function, which fails when you have 
more than one definition of the same literal. I.e. you cannot qualify the 
function to resolve ambiguity.

Other complaints about them:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html


 I don't think it's much worse, but I fail to see how it could be better.


Reasons:

1. It is not a language extension
2. Conflicting names are easily resolved
3. More than one argument is possible
4. The full power of CTFE is available to compute it, rather than the very 
limited C++0x constexpr
5. If you read N2765, it's pretty darned hackish. I.e. there's the "raw" and 
"cooked" mode.


 Which makes me wonder, what does the compiler suggests in the error message
when
 it encounters 01777777777777777777777 ? I suspect it doesn't add the necessary
 quotes, does it?


No, it doesn't. The lexer knows nothing about higher level semantics.

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 12:12 AM, Russel Winder wrote:
 On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:

 Yes, except for something else - the rarity of need for octal literals. The
only
 modern usage I've seen of it is for file permissions.


 What is the use for binary literals or hexadecimal literals, I can't
 think of one.

 Except perhaps specification of register save masks and control status
 work literals -- which is of course where the octal stuff came from in
 the first place in C and when the VAX replaced PDP, hexadecimal was
 rapidly introduced. (*)


I still prefer binary for that. It takes me a senior moment or two to remember 
what bit pattern 0xB is, for example.


 I would suggest that rather than discriminating against people who like
 octal


The phrase "discriminating against people" has a lot of emotional baggage 
associated with it that is irrelevant to this.


 instead of decimal or hexadecimal, the solution of introducing
 0o... in harmony with 0b... and 0x... -- and of course removing the
 leading 0 octal literal convention -- is obviously the right solution.
 It ticks all the boxes.


Except the box of a kitchen sink of features of marginal utility. A feature
that 
can be handled adequately by the library should not be part of the core
language.

And yes, you can make a reasonable case that 0b should be ditched for the same 
reason.

Apr 03 2011

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

"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:in9c9h$134t$1 digitalmars.com...
 On 4/3/2011 12:12 AM, Russel Winder wrote:
 On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:

 Yes, except for something else - the rarity of need for octal literals. 
 The only
 modern usage I've seen of it is for file permissions.


 What is the use for binary literals or hexadecimal literals, I can't
 think of one.

 Except perhaps specification of register save masks and control status
 work literals -- which is of course where the octal stuff came from in
 the first place in C and when the VAX replaced PDP, hexadecimal was
 rapidly introduced. (*)


 I still prefer binary for that. It takes me a senior moment or two to 
 remember what bit pattern 0xB is, for example.


Somtimes I have to wonder if I'm much older than I think I am. I'm exactly 
the same way as you with "moment or two to remember what bit pattern 0xB is, 
for example", and if I'm getting senior moments in my late 20's then 
something is very very wrong ;)

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 1:54 AM, Nick Sabalausky wrote:
 Somtimes I have to wonder if I'm much older than I think I am. I'm exactly
 the same way as you with "moment or two to remember what bit pattern 0xB is,
 for example", and if I'm getting senior moments in my late 20's then
 something is very very wrong ;)


You should be fine as long as you're not tying an onion to your belt!

Apr 03 2011

Adam D. Ruppe <destructionator gmail.com> writes:

Walter Bright wrote:
 And yes, you can make a reasonable case that 0b should be ditched
 for the same reason.


I know people already think of the isIntegral versions of octal
as a hack, but I see that as one reason why binary wouldn't work
as well as a template:

binary!1111_1111_0000_0000

Overflow city! Such long numbers aren't terribly common in octal,
but they /are/ in binary.

Of course, you can just use the string version, so it isn't a
big deal, but nevertheless, it is a difference.


btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)

And if you actually need that, the string version works just fine.

So all in all I don't think it's worth it.

Apr 03 2011

Michel Fortin <michel.fortin michelf.com> writes:

On 2011-04-03 12:04:42 -0400, Adam D. Ruppe <destructionator gmail.com> said:

 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.
 
 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


I've been thinking about the same thing, except instead of having a 
special data type the template would simply take a string:

	template binary(string digits) {
		...
	}

	binary!1111_1111_0000_0000;
	// no error, number "1111_1111_0000_0000" passed as a string to the template.

But the bigger problem is that it doesn't scale beyond base 10:

	template hex(string digits) {
		...
	}

	hex!ABCDEF00;
	// isn't ABCDEF00 an identifier?

So it wouldn't bring us much when it comes to parsing different bases, 
even though it could be used for other things.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 9:28 AM, Michel Fortin wrote:
 So it wouldn't bring us much when it comes to parsing different bases, even
 though it could be used for other things.


That would also get us into the C++0x territory of having "raw" and "cooked" 
tokens, something I really wish to avoid.

Apr 03 2011

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

"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:ina7e9$2kdh$1 digitalmars.com...
 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe <destructionator gmail.com> 
 said:

 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a 
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the 
 template.


I've always thought that we should be able to do something like this:

template foo(int val)
{
    enum foo = val.meta.argString;
}
static assert(foo!(2+3) == "2+3");

Apr 03 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/3/11 1:37 PM, spir wrote:
 On 04/03/2011 07:57 PM, Nick Sabalausky wrote:
 "Michel Fortin"<michel.fortin michelf.com> wrote in message
 news:ina7e9$2kdh$1 digitalmars.com...
 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe<destructionator gmail.com>
 said:

 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the
 template.


 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
 enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


 That's Lisp (or Io): non-evaluated arguments (messages). Next century in
 compiled languages ;-)


No, that's C's last century's "#" prefix.


Andrei

Apr 03 2011

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

"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3093.1301858962.4748.digitalmars-d puremagic.com...
 On 4/3/11, Nick Sabalausky <a a.a> wrote:
 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
     enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


 I wish we had some introspection to get the lines of code inside of a
 function. But it's still pretty cool that you can pass expressions to
 functions and automatically construct delegates. See here:

 import std.stdio;

 void main()
 {
    int x;

    foo(false, x = 5);
    assert(x != 5);

    foo(true, x = 5);
    assert(x == 5);
 }

 void foo(bool doit, int delegate()[] dgs ...)
 {
    if (doit)
        dgs[0]();
 }

 I wonder how many people know about this feature. I just bumped into
 it a few days ago while looking through the docs.


I didn't know that. I think I remember the idea of it being discussed, but I 
didn't know it was in.

Apr 03 2011

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

"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:in8f9e$1h45$1 digitalmars.com...
 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> 
 said:

 On 4/2/2011 4:11 PM, Michel Fortin wrote:
 It's funny that D (the language) has binary notation built-in (which C 
 doesn't
 have) but no octal notation anymore (which C has).


 The problem with the octal literals is, as has been often complained 
 about, people getting surprised by it. I've never heard of anyone being 
 surprised by the binary or hex literals.


 Indeed. Isn't that a good argument for implementing octal literals the 
 same way as binary and hex literals?


Octal is never really needed or used for anything but unix file permissions, 
so I really don't think it matters at all if it happens to be inconsistent.

 I think it's a feature, not a "resort", that library templates can do 
 this well. I think it's far better than C++0x's user defined literals, 
 for example.


 I disagree that it's better. With C++ user defined literals the user 
 doesn't have to find by himself whether the number fits within the range 
 of a regular integer literal and if not fall back to using a string as the 
 template argument instead.


C++'s user defined literals sound like a lexing nightmare to me.

Apr 03 2011

spir <denis.spir gmail.com> writes:

On 04/03/2011 07:57 PM, Nick Sabalausky wrote:
 "Michel Fortin"<michel.fortin michelf.com>  wrote in message
 news:ina7e9$2kdh$1 digitalmars.com...
 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe<destructionator gmail.com>
 said:

 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the
 template.


 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
      enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


That's Lisp (or Io): non-evaluated arguments (messages). Next century in 
compiled languages ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Apr 03 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


I fail to infer how using the word "octal" for an octal literal is 
surprising at all.

This thread is a good example that it's impossible to please everyone. 
Although past discussions made it clear that most everyone found leading 
0 a poor convention for octal numbers, now not only the consensus is 
weaker, but some actually claim a different solution is superior. If 
that were chosen, then all of a sudden octal!777 would have become 
suddenly sexy and so on.

The grass is always greener on the other side...


Andrei

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.
 
 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.
 
 The grass is always greener on the other side...
 
 
 Andrei


I don't think the consensus that a leading 0 is a poor convention for octal
numbers is weaker now - so far nobody wants the old syntax back :)

Apr 02 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/2/11 6:36 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.

 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for octal
 numbers is weaker now - so far nobody wants the old syntax back :)


Some discussions on IRC suggest otherwise.

Andrei

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 04:00, schrieb Andrei Alexandrescu:
 On 4/2/11 6:36 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.

 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for octal
 numbers is weaker now - so far nobody wants the old syntax back :)


 Some discussions on IRC suggest otherwise.
 
 Andrei


Ok. I don't hang out in the D IRC chan because the NG is time-consuming enough
already ;)

Apr 02 2011

bearophile <bearophileHUGS lycos.com> writes:

Andrei:

 Although past discussions made it clear that most everyone found leading 
 0 a poor convention for octal numbers, now not only the consensus is 
 weaker,


The consensus was as much strong as now that the leading zero to denote octals
is bad. But even in past some people (like me) have suggested more than one
replacement syntax (see Bugzilla). So I am seeing nothing new in the
discussions of today.


 If that were chosen, then all of a sudden octal!777 would have become 
 suddenly sexy and so on.


You have no proof of this.

By the way, I am happy of this (unannounced) change.

Bye,
bearophile

Apr 02 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/3/11 2:14 AM, Russel Winder wrote:
 On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but
 hardly octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


 The problem is not that it is a poor solution in isolation, it is
 the conflict between 0b... and 0x.. versus octal!...  Why is octal
 being discriminated against compared to binary and hexadecimal?


It's very simple. You are making a number of fallacious assumptions
which logically lead to a wrong conclusion.

First fallacy is:

 What is the use for binary literals or hexadecimal literals, I can't
 think of one.


Just looking through std/ yields 1849 lines with 0x in them, of which 
many have several instances on the same line.

The second fallacy is assigning equal weight to every feature or 
potential feature. A language should not be a democracy.

The third fallacy is a unidimensional view of consistency. It's very 
easy to first limit the notion of consistency to only one possible 
dimension, to then show that a lot of stuff is inconsistent. In reality 
there are many dimensions of consistency, and choosing their right 
relative importance is much of the difficulty of language design.

Keeping 0x in the language is consistent with the general similarity of 
D with C, C++, Java, and many others.

Eliminating 0777 from the language is consistent with the notion that 
leading zeros are insignificant in regular decimal notation in math. It 
is also consistent with the desire of preventing subtle mistakes made by 
people who make the math-based assumption.

Adding octal!777 to std.conv is consistent with the notion that there 
still are a few uses for octal constants that are worth a presence in 
the standard library. It is also consistent with the desire to foster 
other user-defined literals defined from the same mold.


Andrei

Apr 03 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/3/11 1:40 PM, spir wrote:
 On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:
 Adding octal!777 to std.conv is consistent with the notion that there
 still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other
 user-defined
 literals defined from the same mold.


 What about a general baseNumber template instead?
 ....which would also be trivially "alias-able":
 alias baseNumber!3 base3;


When was last time you've been in a place in life when you could have 
used a base 3 literal?

Andrei

Apr 03 2011

spir <denis.spir gmail.com> writes:

On 04/03/2011 08:49 PM, Andrei Alexandrescu wrote:
 On 4/3/11 1:40 PM, spir wrote:
 On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:
 Adding octal!777 to std.conv is consistent with the notion that there
 still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other
 user-defined
 literals defined from the same mold.


 What about a general baseNumber template instead?
 ....which would also be trivially "alias-able":
 alias baseNumber!3 base3;


 When was last time you've been in a place in life when you could have used a
 base 3 literal?


I'm not stating this point (implicitely); I mean that it would be useful. 
Rather you and others let me think at this by saying the template solution 
(octal!) is more general (than 0o).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Apr 03 2011

spir <denis.spir gmail.com> writes:

On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:
 Adding octal!777 to std.conv is consistent with the notion that there still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other user-defined
 literals defined from the same mold.


What about a general baseNumber template instead?
...which would also be trivially "alias-able":
     alias baseNumber!3 base3;

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


010, etc., will now be errors. They will not be 10 decimal.

Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
09, etc. will of course be errors.

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 01:50, schrieb Walter Bright:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.
 
 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


That feels pretty inconsistent.

Cheers,
- Daniel

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 4:52 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:50, schrieb Walter Bright:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


It is inconsistent. One of the interesting things about "good" user interface 
design is it is awfully inconsistent.

The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't 
octal, and it seemed a pity to break it.

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 03:39, schrieb Walter Bright:
 On 4/2/2011 4:52 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:50, schrieb Walter Bright:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 It is inconsistent. One of the interesting things about "good" user interface
 design is it is awfully inconsistent.
 
 The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't
 octal, and it seemed a pity to break it.


They were octal, it just didn't make a difference. I don't see a reason to use
them (if not as octals) anyway.

Time will tell but I wouldn't be surprised if sooner or later somebody wonders
why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)

Cheers,
- Daniel

Apr 02 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/2/2011 6:44 PM, Daniel Gibson wrote:
 Time will tell but I wouldn't be surprised if sooner or later somebody wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)


They might. We'll see.

Apr 02 2011

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

"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in8jko$knb$7 digitalmars.com...
 Am 03.04.2011 03:39, schrieb Walter Bright:
 On 4/2/2011 4:52 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:50, schrieb Walter Bright:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without 
 complaint. 08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 It is inconsistent. One of the interesting things about "good" user 
 interface
 design is it is awfully inconsistent.

 The thing is, I ran into a bunch of D code that used 01, 03, etc. They 
 weren't
 octal, and it seemed a pity to break it.


 They were octal, it just didn't make a difference. I don't see a reason to 
 use
 them (if not as octals) anyway.

 Time will tell but I wouldn't be surprised if sooner or later somebody 
 wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner 
 cases ;)


Yea, but I bet people would also complain if it were disallowed. "There's no 
ambiguity here! Why's it whining about something that's obviously guaranteed 
to work?!"

Apr 03 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 09:44, Daniel Gibson wrote:
 Am 03.04.2011 03:39, schrieb Walter Bright:
 On 4/2/2011 4:52 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:50, schrieb Walter Bright:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 It is inconsistent. One of the interesting things about "good" user interface
 design is it is awfully inconsistent.

 The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't
 octal, and it seemed a pity to break it.


 They were octal, it just didn't make a difference. I don't see a reason to use
 them (if not as octals) anyway.

 Time will tell but I wouldn't be surprised if sooner or later somebody wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)

 Cheers,
 - Daniel


No need to be surprised, people are already complaining languages 
supporting the 0nnn notation that why 08, 09 does not compile. :)

e.g.

08 in Python 2: 
http://stackoverflow.com/questions/336181/python-invalid-token
09 in Java: 
http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 2:31 AM, KennyTM~ wrote:
 No need to be surprised, people are already complaining languages supporting
the
 0nnn notation that why 08, 09 does not compile. :)

 e.g.

 08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
 09 in Java:
 http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized



I love the answer given: "There is no 9 in octal"

Apr 03 2011

bearophile <bearophileHUGS lycos.com> writes:

Walter:

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


Isn't this a corner case of the general rule? (corner cases are bad).

Bye,
bearophile

Apr 02 2011

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

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:in8dfe$1e32$1 digitalmars.com...
 Walter:

 Also, the literals 00, 01, ..., 07 will still be accepted without 
 complaint. 08,
 09, etc. will of course be errors.


 Isn't this a corner case of the general rule? (corner cases are bad).


"(corner cases are bad)"

So is stealing, but no one ever bitches if you pick up a penny off the 
ground. Yea, it's a corner case, but it's trivial enough not to actually 
matter. Guaranteed, people would bitch the other way too, so it's "dammed if 
we do, dammed if we don't" anyway.

Apr 03 2011

Francisco Almeida <francisco.m.almeida gmail.com> writes:

Walter Bright Wrote:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.
 
 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


This doesn't feel right, though. Either you permit leading numbers with leading
zeroes to be read as decimals, or you forbid them unless they are 0x... or
0b... .

I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?

Granted, the 0123 syntax was error prone and we're all glad it's gone, but
aren't there better alternatives such as 0o123 or 0q123, for example?

Apr 02 2011

Daniel Gibson <metalcaedes gmail.com> writes:

Am 03.04.2011 02:23, schrieb Francisco Almeida:
 Walter Bright Wrote:
 
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


 This doesn't feel right, though. Either you permit leading numbers with
leading zeroes to be read as decimals, or you forbid them unless they are 0x...
or 0b... .


I agree.

 
 I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?


No, it's a template, so it's evaluated at compile-time and doesn't impact
(runtime) performance.

 
 Granted, the 0123 syntax was error prone and we're all glad it's gone, but
aren't there better alternatives such as 0o123 or 0q123, for example?
 


How often do you use octal numbers?

Apr 02 2011

Francisco Almeida <francisco.m.almeida gmail.com> writes:

== Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 I am concerned about the choice of relegating a kind of number literal to a




 No, it's a template, so it's evaluated at compile-time and doesn't impact
 (runtime) performance.


If there is no runtime performance penalty, then it's fine.

 Granted, the 0123 syntax was error prone and we're all glad it's gone, but








Good point.

Apr 02 2011

KennyTM~ <kennytm gmail.com> writes:

On Apr 3, 11 07:50, Walter Bright wrote:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without
 complaint. 08, 09, etc. will of course be errors.


Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ 
won't? Or is this considered just a DMD extension?

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 2:33 AM, KennyTM~ wrote:
 On Apr 3, 11 07:50, Walter Bright wrote:
 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without
 complaint. 08, 09, etc. will of course be errors.


 Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ won't?
 Or is this considered just a DMD extension?


It should be part of the spec.

Apr 03 2011

spir <denis.spir gmail.com> writes:

On 04/03/2011 11:39 AM, Walter Bright wrote:
 On 4/3/2011 2:31 AM, KennyTM~ wrote:
 No need to be surprised, people are already complaining languages supporting
the
 0nnn notation that why 08, 09 does not compile. :)

 e.g.

 08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
 09 in Java:
 http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized



 I love the answer given: "There is no 9 in octal"


I love that one: "10 is how many digits you have, whereas 010 is is what you 
get if you don't count your thumbs."

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Apr 03 2011

Russel Winder <russel russel.org.uk> writes:

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is=20
 surprising at all.


The problem is not that it is a poor solution in isolation, it is the
conflict between 0b... and 0x.. versus octal!...  Why is octal being
discriminated against compared to binary and hexadecimal?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Apr 03 2011

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

"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.3055.1301814881.4748.digitalmars-d puremagic.com...
On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


The problem is not that it is a poor solution in isolation, it is the
conflict between 0b... and 0x.. versus octal!...  Why is octal being
discriminated against compared to binary and hexadecimal?


To be perfectly blunt, it's because octal...well, sucks. It's useless 
compared to binary and hex and just isn't really deserving of a special 
notation anyway. Even more so since the rare uses of it are possible in D 
without it being part of the language. Binary and hex, OTOH, are useful (I 
use hex very frequently. And I would get a lot of use out of binary if I 
actually had time to do low-level work like I used to).

That said, I woudn't have a problem with 0o... being used instead (Although 
I'd actually prefer 0c...). But I have a hard time understanding why people 
are making such a big deal out of something that practically no one ever 
uses anyway. Consistency is nice, sure, but when it's such a trival 
corner-case as octal: Why even care? This isn't the color of the bikeshed, 
this is the *shade* of color on the underside of the trim on a window that's 
one foot off the ground and completely blocked by a big tree.

Apr 03 2011

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 4/3/11 6:24 AM, spir wrote:
 On 04/03/2011 10:37 AM, Nick Sabalausky wrote:
 That said, I woudn't have a problem with 0o... being used instead
 (Although
 I'd actually prefer 0c...). But I have a hard time understanding why
 people
 are making such a big deal out of something that practically no one ever
 uses anyway. Consistency is nice, sure, but when it's such a trival
 corner-case as octal: Why even care? This isn't the color of the
 bikeshed,
 this is the *shade* of color on the underside of the trim on a window
 that's
 one foot off the ground and completely blocked by a big tree.


 What I fail to see is the advantage of introducing an exception for
 octal. Either it is left out of the language (including stdlib, possibly
 having around a 3rd party hack for it), or the same pattern is used as
 for hex and bin.


Right now octal constants are indeed out of the language.

 A point is stating a threshold of usefulness. Seems nearly everyone
 agrees octal is not worth it: then just say bye. If it kept instead
 because of historical reasons (what I guess is the case), then just
 *fix* the syntax. Introducing a feature (an exception) for a nearly
 useless notion is weird.


This is not a feature. It is effectively "bye".


Thanks,

Andrei

Apr 03 2011

Adam D. Ruppe <destructionator gmail.com> writes:

spir wrote:
 What I fail to see is the advantage of introducing an exception for
 octal.


Octal isn't the exception. Of all the infinite number bases out there,
octal is the one done in the most generic way. (In fact, it'd
probably be a reasonably simple change to make it alias base!8 octal;
or something like that)

The exceptions are decimal, hex, and binary. Each one has reasoning:

decimal: that's the way we normally talk and think. We need a
         starting point somewhere, so this is the natural choice.

hex:     commonly used and cannot be easily written as a decimal
         literal. Piles upon piles of existing code depend on it.

binary:  Incredibly useful, not easily written as a decimal. The
         case for giving it special treatment isn't as strong as
         hex, but it follows the same reasoning. (Actually, in
         code that I write freshly, I use binary literals more
         often than hex. Like Walter, my brain is slow at making
         masks out of hex.)



Anything can follow the same pattern as octal. Not anything can
be shoved into the language.

Apr 03 2011

Walter Bright <newshound2 digitalmars.com> writes:

On 4/3/2011 4:24 AM, spir wrote:
 Introducing a
 feature (an exception) for a nearly useless notion is weird.


The whole point of this is it is not introducing a feature. It's using existing 
features to emulate a feature that is being removed.

Apr 03 2011

spir <denis.spir gmail.com> writes:

On 04/03/2011 10:37 AM, Nick Sabalausky wrote:
 That said, I woudn't have a problem with 0o... being used instead (Although
 I'd actually prefer 0c...). But I have a hard time understanding why people
 are making such a big deal out of something that practically no one ever
 uses anyway. Consistency is nice, sure, but when it's such a trival
 corner-case as octal: Why even care? This isn't the color of the bikeshed,
 this is the *shade* of color on the underside of the trim on a window that's
 one foot off the ground and completely blocked by a big tree.


What I fail to see is the advantage of introducing an exception for octal. 
Either it is left out of the language (including stdlib, possibly having around 
a 3rd party hack for it), or the same pattern is used as for hex and bin.
A point is stating a threshold of usefulness. Seems nearly everyone agrees 
octal is not worth it: then just say bye. If it kept instead because of 
historical reasons (what I guess is the case), then just *fix* the syntax. 
Introducing a feature (an exception) for a nearly useless notion is weird.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Apr 03 2011

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

On Sat, 02 Apr 2011 22:14:47 -0400, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 Am 03.04.2011 04:00, schrieb Andrei Alexandrescu:
 On 4/2/11 6:36 PM, Daniel Gibson wrote:
 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is  
 surprising at
 all.

 This thread is a good example that it's impossible to please  
 everyone. Although
 past discussions made it clear that most everyone found leading 0 a  
 poor
 convention for octal numbers, now not only the consensus is weaker,  
 but some
 actually claim a different solution is superior. If that were chosen,  
 then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for  
 octal
 numbers is weaker now - so far nobody wants the old syntax back :)


 Some discussions on IRC suggest otherwise.

 Andrei


 Ok. I don't hang out in the D IRC chan because the NG is time-consuming  
 enough
 already ;)


Oh how true this is :)

-Steve

Apr 04 2011

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

On Sun, 03 Apr 2011 03:14:31 -0400, Russel Winder <russel russel.org.uk>  
wrote:

 On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


 The problem is not that it is a poor solution in isolation, it is the
 conflict between 0b... and 0x.. versus octal!...  Why is octal being
 discriminated against compared to binary and hexadecimal?


This currently works in D:

auto hexvalue = 0XABCD;
auto binvalue = 0B1011; // BTW, walter, this is 0xB, I always remember it,  
because A is 10, and in binary that's 1010, add 1 for B ;)

So if you have the 0o syntax, wouldn't you need the 0O syntax to be  
'non-discriminatory'?  And if we have that, I think your argument loses  
all credibility.  You can't argue discrimination unless you are arguing  
for the 0O syntax, which is non-defensible.

I agree with everyone who says octal!x is good enough -- nobody uses octal  
except for unix permissions, so anyone who's arguing against the syntax is  
doing it from a theoretical position, since it probably doesn't affect  
them.

-Steve

Apr 04 2011

Russel Winder <russel russel.org.uk> writes:

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2011-04-04 at 08:50 -0400, Steven Schveighoffer wrote:
[ . . . ]
 I agree with everyone who says octal!x is good enough -- nobody uses octa=


 except for unix permissions, so anyone who's arguing against the syntax i=


 doing it from a theoretical position, since it probably doesn't affect =


 them.


Not entirely true, but views have been aired, decisions ratified, so it
is time to move on with the status quo -- probably "Whatever You Want",
but maybe "What You're Proposing" -- mostly thought this is now a
non-issue, is there anything else to be said?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Apr 04 2011

D Programming

C/C++ Programming

Other

digitalmars.D - Re: Re: Is the world coming to an end?