"Sean Kelly" <sean@f4.ca> wrote in message news:c92blc$23vu$1@digitaldaemon.com...
> I agree.  The standard leading zero notation for octal is misleading.  I'd
much
> prefer an obvious and consistent scheme like the one you describe.

But, as you say, it's "standard". This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language, system manuals, data sheets, etc.

thats why i put (==NUMBER) behind 0xNUMBER..

means without prefix works as well..

and 0NUMBER == NUMBER, too.. unlike c-shit

"Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag news:c90oc6$2r0n$1@digitaldaemon.com...
> depends whether unprefixed numbers still represent decimal, or are now
errors.
>
> I would be in favour of the following valid forms
>
>     0x90AB    -    hex
>     0d7890    -    decimal
>     0o6701    -    octal
>     0b1010    -    binary
>
> _and_
>
>     7890        -    decimal
>
> With 06701 for octal being invalid
>
> "Stephan Wienczny" <wienczny@web.de> wrote in message news:c90ckl$28pr$1@digitaldaemon.com...
> > That shouldn't be a problem to implement. Do we want that?
> >
> > davepermen wrote:
> > > i'd prefer to break it. i had more subtle breaks of my code because i
forgot
> > > to remember that 0 in front fucks up my numbers.
> > >
> > > 0xNUMBER == hex
> > > 0dNUMBER == dec (==NUMBER)
> > > 0oNUMBER == oct
> > > 0bNUMBER == binary
> > >
> > > others?
> > >
>
>

>But, as you say, it's "standard". This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language, system manuals, data sheets, etc.

I have a couple of Microsoft books around here which use things like  0Fh  -- which apparently is 15 in hex. But that's Microsoft for ya.

its only standart as you defined so.

heck, reimplement the ; after struct X {} and class X {}, thats how c++ does it!

and drop the gc!

and all the other stuff you changed!

this is minor, but its a bad design that should finally got rid of!

i mean really, who invented that shit? its the worst design style ever 0100 != 100. NEVER..

make it an error, and you're done.. so you have to write 0d0100 == 100 == _100..

nothing is standart in D. its your choise. be wise, don't follow useless old habbits. you kill your language with such things. newbies hate such flaws (i did in c++), and people who know the languages with the bug, will be glad to get rid of.

believe me.

"Walter" <newshound@digitalmars.com> schrieb im Newsbeitrag news:c92vs3$2i9$3@digitaldaemon.com...
>
> "Sean Kelly" <sean@f4.ca> wrote in message news:c92blc$23vu$1@digitaldaemon.com...
> > I agree.  The standard leading zero notation for octal is misleading.
I'd
> much
> > prefer an obvious and consistent scheme like the one you describe.
>
> But, as you say, it's "standard". This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language,
system
> manuals, data sheets, etc.
>
>

"Walter" <newshound@digitalmars.com> wrote in message news:c92vs3$2i9$3@digitaldaemon.com...
>
> "Sean Kelly" <sean@f4.ca> wrote in message news:c92blc$23vu$1@digitaldaemon.com...
> > I agree.  The standard leading zero notation for octal is misleading.  I'd
> much
> > prefer an obvious and consistent scheme like the one you describe.
>
> But, as you say, it's "standard". This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language, system manuals, data sheets, etc.

But it's comparatively rare - I'd suspect it would be the rarest used in D. And an overt breaking change is pretty easy to cope with.

I really think D should step out of the closet here and declare that everyone else is wrong, and lead the way to the right path.

> thats why i put (==NUMBER) behind 0xNUMBER..
>
> means without prefix works as well..
>
> and 0NUMBER == NUMBER, too.. unlike c-shit

Sorry, mate. It's early.

Can you explain that one again?

A bit strongly expressed, but I think you've hit the nail on the head. :-)

"davepermen" <davepermen@hotmail.com> wrote in message news:c93249$6cm$1@digitaldaemon.com...
> its only standart as you defined so.
>
> heck, reimplement the ; after struct X {} and class X {}, thats how c++ does it!
>
> and drop the gc!
>
> and all the other stuff you changed!
>
> this is minor, but its a bad design that should finally got rid of!
>
> i mean really, who invented that shit? its the worst design style ever 0100 != 100. NEVER..
>
> make it an error, and you're done.. so you have to write 0d0100 == 100 == _100..
>
> nothing is standart in D. its your choise. be wise, don't follow useless old habbits. you kill your language with such things. newbies hate such flaws (i did in c++), and people who know the languages with the bug, will be glad to get rid of.
>
> believe me.
>
> "Walter" <newshound@digitalmars.com> schrieb im Newsbeitrag news:c92vs3$2i9$3@digitaldaemon.com...
> >
> > "Sean Kelly" <sean@f4.ca> wrote in message news:c92blc$23vu$1@digitaldaemon.com...
> > > I agree.  The standard leading zero notation for octal is misleading.
> I'd
> > much
> > > prefer an obvious and consistent scheme like the one you describe.
> >
> > But, as you say, it's "standard". This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language,
> system
> > manuals, data sheets, etc.
> >
> >
>
>

NUMBER == any number (do a string replace with 12345.. :D

i've written decimal: 0d12345 (==12345)

here, its fucking late.. need sleep now

"Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag news:c932t4$7gk$1@digitaldaemon.com...
> > thats why i put (==NUMBER) behind 0xNUMBER..
> >
> > means without prefix works as well..
> >
> > and 0NUMBER == NUMBER, too.. unlike c-shit
>
> Sorry, mate. It's early.
>
> Can you explain that one again?
>
>

he just dropped support for old style casts, and still wants support for that piece of shit-relict. i mean, what USE does it have?

casts at least gave something that was useful...


"Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag news:c932t5$7gk$2@digitaldaemon.com...
> A bit strongly expressed, but I think you've hit the nail on the head. :-)
>
> "davepermen" <davepermen@hotmail.com> wrote in message news:c93249$6cm$1@digitaldaemon.com...
> > its only standart as you defined so.
> >
> > heck, reimplement the ; after struct X {} and class X {}, thats how c++
does
> > it!
> >
> > and drop the gc!
> >
> > and all the other stuff you changed!
> >
> > this is minor, but its a bad design that should finally got rid of!
> >
> > i mean really, who invented that shit? its the worst design style ever
0100
> > != 100. NEVER..
> >
> > make it an error, and you're done.. so you have to write 0d0100 == 100
==
> > _100..
> >
> > nothing is standart in D. its your choise. be wise, don't follow useless
old
> > habbits. you kill your language with such things. newbies hate such
flaws (i
> > did in c++), and people who know the languages with the bug, will be
glad to
> > get rid of.
> >
> > believe me.
> >
> > "Walter" <newshound@digitalmars.com> schrieb im Newsbeitrag news:c92vs3$2i9$3@digitaldaemon.com...
> > >
> > > "Sean Kelly" <sean@f4.ca> wrote in message news:c92blc$23vu$1@digitaldaemon.com...
> > > > I agree.  The standard leading zero notation for octal is
misleading.
> > I'd
> > > much
> > > > prefer an obvious and consistent scheme like the one you describe.
> > >
> > > But, as you say, it's "standard". This common notation for octal
numbers
> > > goes beyond C; it's used in other languages and in assembly language,
> > system
> > > manuals, data sheets, etc.
> > >
> > >
> >
> >
>
>

>this is minor, but its a bad design that should finally got rid of!

>nothing is standart in D. its your choise. be wise, don't follow useless old habbits. you kill your language with such things. newbies hate such flaws (i did in c++), and people who know the languages with the bug, will be glad to get rid of.


Exactly! If you're creating a _new_language that fixes the flaws in C/C++, then just _do_ it (place swoosh here)! And not just half way or someone else will come along and trump you next year, rather than ten years from now.