Lutger wrote:
...
>
> unittest
> {
> alias Flags!q{ do_nothing, walk_dog, cook_breakfast, deliver_newspaper,
> visit_miss_kerbopple, morning_task = walk_dog | cook_breakfast,
> wash_covers } Todo;
>
> Todo list1 = Todo.do_nothing;
> assert( list1 == 1 );
> list1 |
Lutger wrote:
...
> struct Flags(string members, T = uint)
> {
> static assert( is(T : ulong), "Wrong underlying type of Flags: must be
> integral not " ~ T.stringof );
>
> mixin( genFlags(members) );
I screwed up of course, this must be:
mixin( genFlags(members, T.stringof) );
>
Andrei Alexandrescu wrote:
> On 03/28/2010 03:44 AM, Lutger wrote:
(...)
>> I like this idea of implementing a flag type and tried to work something
>> out. Instead of implementing the overloads, it is also possible to
>> generate an enum via CTFE inside a struct and forward with alias this,
>> wh
On 03/28/2010 06:03 PM, bearophile wrote:
The construct defines at compile-time a property for each given name.<
A costant (enum) not a property, sorry.
So this:
alias Flags!q{ A, B, C } Foo;
Becomes equivalent to:
struct Foo {
enum uint A = 1<< 0;
enum uint B = 1<< 1;
enum
Andrei Alexandrescu:
> For what it's worth, Walter and I were talking three years ago about a
> "new alias" feature:
>
> template Flags(new alias Names...) { ... }
>
> "new alias" means that you may pass to Flags symbols that haven't been
> defined. With that feature in place, Flags could be us
>The construct defines at compile-time a property for each given name.<
A costant (enum) not a property, sorry.
So this:
alias Flags!q{ A, B, C } Foo;
Becomes equivalent to:
struct Foo {
enum uint A = 1 << 0;
enum uint B = 1 << 1;
enum uint C = 1 << 2;
private uint _data;
Andrei Alexandrescu:
> What I think this is lacking is the ability to
> predefine flags that are a combination of other flags. For example, some
> file open flags could define DEFAULT_READ as READ|SHARED. I'm not sure
> how to express that.
It's not an enum, it's a struct, that contains a singl
On 03/28/2010 03:44 AM, Lutger wrote:
bearophile wrote:
To invent a software you can first find the best syntax. This seems a nice
syntax, very similar to the enum one (that ubyte is optional):
flags ubyte Todo {
do_nothing,
walk_dog,
cook_breakfast,
deliver_newspaper,
On 03/27/2010 09:02 AM, Simen kjaeraas wrote:
Andrei Alexandrescu wrote:
alias Flags!(ubyte, "do_nothing",
"walk_dog"
"cook_breakfast"
"deliver_newspaper"
"visit_miss_kerbopple"
"wash_covers") Todo;
I encourage you to code that up and see how it swims. We need to stop
inventing syntax for any
On Mar 28, 10 18:56, Yigal Chripun wrote:
KennyTM~ Wrote:
On Mar 26, 10 18:52, yigal chripun wrote:
KennyTM~ Wrote:
On Mar 26, 10 05:46, yigal chripun wrote:
while it's true that '?' has one unicode value for it, it's not true for all
sorts of diacritics and combine code-points. So your a
KennyTM~ Wrote:
> On Mar 26, 10 18:52, yigal chripun wrote:
> > KennyTM~ Wrote:
> >
> >> On Mar 26, 10 05:46, yigal chripun wrote:
> >>>
> >>> while it's true that '?' has one unicode value for it, it's not true for
> >>> all sorts of diacritics and combine code-points. So your approach is to
>
Lutger:
>I can brush it up and post the code later if you want, but it's not so pretty.<
This syntax is not pretty, but I think it can be acceptable:
alias Flags!q{
do_nothing,
walk_dog,
cook_breakfast,
deliver_newspaper,
visit_miss_kerbopple,
wash_covers
} Todo;
With opt
bearophile wrote:
> Lutger:
>> alias Flags!q{ do_nothing,
>>walk_dog,
>>cook_breakfast,
>>deliver_newspaper,
>>visit_miss_kerbopple,
>>wash_covers } Todo;
>
> That's better.
> But you have missed the optional type :-)
Lutger:
> alias Flags!q{ do_nothing,
>walk_dog,
>cook_breakfast,
>deliver_newspaper,
>visit_miss_kerbopple,
>wash_covers } Todo;
That's better.
But you have missed the optional type :-)
Bye,
bearophile
bearophile wrote:
> To invent a software you can first find the best syntax. This seems a nice
> syntax, very similar to the enum one (that ubyte is optional):
>
> flags ubyte Todo {
> do_nothing,
> walk_dog,
> cook_breakfast,
> deliver_newspaper,
> visit_miss_kerbopple,
>
Andrei Alexandrescu Wrote:
> On 03/26/2010 06:26 PM, Walter Bright wrote:
> > KennyTM~ wrote:
> >> On Mar 26, 10 11:32, Walter Bright wrote:
> >>> Nick Sabalausky wrote:
> Supporting it means it will "silently and disastrously break code"
> from anyone who tries to use a leading zero and
KennyTM~ wrote:
On Mar 26, 10 05:46, yigal chripun wrote:
while it's true that '?' has one unicode value for it, it's not true
for all sorts of diacritics and combine code-points. So your approach
is to pass the responsibility for that to the end user which in
99.% will not handle t
Andrei Alexandrescu wrote:
alias Flags!(ubyte, "do_nothing",
"walk_dog"
"cook_breakfast"
"deliver_newspaper"
"visit_miss_kerbopple"
"wash_covers") Todo;
I encourage you to code that up and
"Walter Bright" wrote in message
news:hojjk3$3c...@digitalmars.com...
> Andrei Alexandrescu wrote:
>> On 03/26/2010 06:26 PM, Walter Bright wrote:
>>> KennyTM~ wrote:
On Mar 26, 10 11:32, Walter Bright wrote:
> Nick Sabalausky wrote:
>> Supporting it means it will "silently and disas
On 03/26/2010 02:01 PM, Walter Bright wrote:
Walter Bright wrote:
I'm not sure why this error is happening, it definitely has something
to do with the mixin. Let me look into it some more.
Bug report and fix: http://d.puremagic.com/issues/show_bug.cgi?id=4011
Awesome!
Nick Sabalausky wrote:
Anyway, this is what I'm doing, and it's giving me a conflict error on the
call to 'bar' in 'main' with DMD 1.056 (fortunately, however, it seems to
work fine in 2.042, so I guess the situation's improved in D2):
The mixins obscure what is going on. The same error is rep
Andrei Alexandrescu wrote:
On 03/26/2010 06:26 PM, Walter Bright wrote:
KennyTM~ wrote:
On Mar 26, 10 11:32, Walter Bright wrote:
Nick Sabalausky wrote:
Supporting it means it will "silently and disastrously break code"
from anyone who tries to use a leading zero and *isn't* a C guru,
You d
On 03/26/2010 06:26 PM, Walter Bright wrote:
KennyTM~ wrote:
On Mar 26, 10 11:32, Walter Bright wrote:
Nick Sabalausky wrote:
Supporting it means it will "silently and disastrously break code"
from anyone who tries to use a leading zero and *isn't* a C guru,
You don't need to be a guru to kn
KennyTM~ wrote:
On Mar 26, 10 11:32, Walter Bright wrote:
Nick Sabalausky wrote:
Supporting it means it will "silently and disastrously break code"
from anyone who tries to use a leading zero and *isn't* a C guru,
You don't need to be a guru to know that. I was once a C newbie, and
never had
On Mar 26, 10 18:52, yigal chripun wrote:
KennyTM~ Wrote:
On Mar 26, 10 05:46, yigal chripun wrote:
while it's true that '?' has one unicode value for it, it's not true for all
sorts of diacritics and combine code-points. So your approach is to pass the
responsibility for that to the end us
On Mar 26, 10 11:32, Walter Bright wrote:
Nick Sabalausky wrote:
Supporting it means it will "silently and disastrously break code"
from anyone who tries to use a leading zero and *isn't* a C guru,
You don't need to be a guru to know that. I was once a C newbie, and
never had any trouble with
Andrei Alexandrescu:
> Could you please paste C# code doing that here? Then we have a good
> baseline to compare the D implementation with.
It's hard to write such things, you have to be an expert C# programmer (you
have to write C# code that operates on the AST or the language of the virtual
Walter Bright wrote:
I'm not sure why this error is happening, it definitely has something to
do with the mixin. Let me look into it some more.
Bug report and fix: http://d.puremagic.com/issues/show_bug.cgi?id=4011
"bearophile" wrote in message
news:hoif0r$v8...@digitalmars.com...
> Nick Sabalausky:
>> I fear it's probably too late for that for D, but I do like it very much.
>> If
>> I ever make a C-style langauge myself, I'll definitely consider something
>> like that.
>
> Adding to dmd a few warnings act
Aelxx:
> In my embedded C projects I always use
> u8, i8
> u16, i16
> u32, i32
> f32 for floats
> and they are all defined in user's header file, surely IDE highlights them
> as keywords :), so no need for language changes =).
D tries to give sensible defaults, good for most programmers, also to
Nick Sabalausky:
>A *lot* of D's design has already been based around the idea of C code doing
>either the same thing or erroring when compiled for D. Plus, Walter loves that
>strategy, and hates extra warnings. I'd love for it to happen, but I guess I'm
>just saying "I ain't holdin my breath!"
Walter Bright:
>The wchar and dchar stem from the popular WORD and DWORD sizes on the x86
>platforms. wchar_t is of course "wide character" for C, and is often used for
>UTF-16 at least on Windows platforms. Confusingly, wchar_t on Linux is 32
>bits.<
>From such comments of yours, and from the
On 03/26/2010 12:47 AM, Adam D. Ruppe wrote:
On Thu, Mar 25, 2010 at 04:52:29PM -0500, Andrei Alexandrescu wrote:
It does work well, but there's one more issue: the type of octal!x is
always ulong. To make the code industrial strength, you should observe
the usual D rules:
I think I made it wo
Nick Sabalausky:
> I fear it's probably too late for that for D, but I do like it very much. If
> I ever make a C-style langauge myself, I'll definitely consider something
> like that.
Adding to dmd a few warnings activated by a compiler switch that help avoid
bugs in porting C->D2 is an additi
Nick Sabalausky wrote:
Bitfields in general: Very common need for systems programming, just ask
Walter how many times he's ANDed or ORed a bitmask in his career. Phobos's
To make this conversation a little less confusing, I think the term you
should be using here is 'bitmasks'.
Walter Bright Wrote:
>
> That's true, '?' can have different encodings, such as for EBCDIC and
> RADIX50.
> Those formats are dead, however, and ASCII has won. D is specifically a
> Unicode
> language (a superset of ASCII) and '?' has a single defined value for it.
>
> Yes, Unicode has some
KennyTM~ Wrote:
> On Mar 26, 10 05:46, yigal chripun wrote:
> >
> > while it's true that '?' has one unicode value for it, it's not true for
> > all sorts of diacritics and combine code-points. So your approach is to
> > pass the responsibility for that to the end user which in 99.% will not
Rainer Deyke wrote:
On 3/25/2010 23:40, Walter Bright wrote:
Rainer Deyke wrote:
I don't mind octal literals, but '0177' is a horrible syntax. *Every*
*single* *time* that I used that syntax in C or C++, I really meant to
use a decimal.
I'm curious what tempted you to use a leading 0 in the f
"bearophile" wrote :
> Regarding base type names I have proposed :
> byte => sbyte
> wchar => char16 (or shortchar)
> dchar => char32 (or intchar)
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3850
> http://d.puremagic.com/issues/show_bug.cgi?id=3936
>
> Bye,
> bearophile
>
In my embedded C p
"Walter Bright" wrote in message
news:hoh85i$1kb...@digitalmars.com...
> bearophile wrote:
>> The wchar/dchar are short names, easy to write, but for me and a person
>> I've
>> shown/taught D it doesn't result easy to remember their size in bytes.
>> "w"
>> stands for wide, "d" for double, this
"BCS" wrote in message
news:a6268ff11bc38cc9a74b1997...@news.digitalmars.com...
> Hello Nick,
>
>> I fear it's probably too late for that for D, but I do like it very
>> much.
>
> Why? The proposal is merely a compiler implementation detail rather than a
> language feature. It could even be done
"BCS" wrote in message
news:a6268ff11b928cc9a720a299...@news.digitalmars.com...
> Hello Walter,
>
>> bearophile wrote:
>>
>>> Nope, here I have suggested to turn leading zeros in syntax errors:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3837
>>>
>> Right, but that doesn't help those who wi
"Walter Bright" wrote in message
news:hohhnn$252...@digitalmars.com...
> Don wrote:
>> I've done it with powers of 10:
>> 001,
>> 010,
>> 100
>>
>> and then wondered why my code was wrong. It's the only time in my life
>> I've ever used an octal literal.
>
> I see that and it screams BINARY to m
"Andrei Alexandrescu" wrote in message
news:hoh8eb$1kb...@digitalmars.com...
> On 03/25/2010 09:38 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:4babc1f7.6080...@erdani.org...
>>> On 03/25/2010 02:52 PM, Nick Sabalausky wrote:
I can agree mixins are a per
On 3/25/2010 23:40, Walter Bright wrote:
> Rainer Deyke wrote:
>> I don't mind octal literals, but '0177' is a horrible syntax. *Every*
>> *single* *time* that I used that syntax in C or C++, I really meant to
>> use a decimal.
>
> I'm curious what tempted you to use a leading 0 in the first plac
Don wrote:
I've done it with powers of 10:
001,
010,
100
and then wondered why my code was wrong. It's the only time in my life
I've ever used an octal literal.
I see that and it screams BINARY to me, not decimal!
I guess I'm not sure why it never was a problem for me. It's just "oh, that's
Rainer Deyke wrote:
I don't mind octal literals, but '0177' is a horrible syntax. *Every*
*single* *time* that I used that syntax in C or C++, I really meant to
use a decimal.
I'm curious what tempted you to use a leading 0 in the first place.
On Thu, Mar 25, 2010 at 04:52:29PM -0500, Andrei Alexandrescu wrote:
> It does work well, but there's one more issue: the type of octal!x is
> always ulong. To make the code industrial strength, you should observe
> the usual D rules:
I think I made it work. Also used template constraints to pre
Walter Bright wrote:
Nick Sabalausky wrote:
(I used C for years without being aware of that octal syntax - it's
only by dumb luck I didn't try to use a leading zero).
It is on the 3rd page of chapter 2 in K&R (and chapter 2 is the first
chapter of the specification).
A mitigating factor is
On 3/25/2010 17:52, Walter Bright wrote:
> One thing is clear, though. 0177 is never going to be a decimal number
> in D, because it will silently and disastrously break code translated
> from C. The only choice is to support 0177 as octal or make it a syntax
> error. I'd rather support them.
I do
Hello Nick,
I fear it's probably too late for that for D, but I do like it very
much.
Why? The proposal is merely a compiler implementation detail rather than
a language feature. It could even be done as part of a lint like tool.
--
... <
Nick Sabalausky wrote:
(I used C for years without being aware of that octal
syntax - it's only by dumb luck I didn't try to use a leading zero).
It is on the 3rd page of chapter 2 in K&R (and chapter 2 is the first chapter of
the specification).
A mitigating factor is who uses leading 0's
Hello Walter,
bearophile wrote:
Nope, here I have suggested to turn leading zeros in syntax errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3837
Right, but that doesn't help those who wish to use leading 0s.
Who wants to do that?
--
... <
Nick Sabalausky wrote:
Supporting it means it will "silently and disastrously break code" from
anyone who tries to use a leading zero and *isn't* a C guru,
You don't need to be a guru to know that. I was once a C newbie, and never had
any trouble with it.
It isn't just C, either, the same sy
Nick Sabalausky:
> As long as we're bikeshedding on type names,
"There are only two hard things in Computer Science: cache invalidation and
naming things" ^_^
>I do find it misleading that "char" represents a code-unit while still calling
>itself a "character".<
The development of the BitC la
On 03/25/2010 09:38 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:4babc1f7.6080...@erdani.org...
On 03/25/2010 02:52 PM, Nick Sabalausky wrote:
I can agree mixins are a perfectly fine interim solution for anything not
already in the language, and for truly obscure nee
bearophile wrote:
The wchar/dchar are short names, easy to write, but for me and a person I've
shown/taught D it doesn't result easy to remember their size in bytes. "w"
stands for wide, "d" for double, this is easy to remember. But how wide is
wide? That's why I have suggested to adopt more desc
"Clemens" wrote in message
news:hogss7$11n...@digitalmars.com...
>
> How about a command line argument to DMD which can be used to aid in
> porting legacy C code? It would cause the compiler to generate a warning
> (or error if you wish) for every occurrence of an ambiguous construct like
> th
"bearophile" wrote in message
news:hoh07b$16k...@digitalmars.com...
> Walter Bright:
>
>>Yes, we can endlessly rename keywords, but in the end, what does that
>>accomplish that would compensate for upending every D program in
>>existence?<
>
> I can list few pro/cons, but then the decision is n
Clemens:
>a command line argument to DMD which can be used to aid in porting legacy C
>code?<
That's a nice idea, thank you for inventing it. Time ago I was vaguely thinking
about something similar, but not quite.
DMD1 has: -d allow deprecated features
So D2 can grow a command line switch as (
"Andrei Alexandrescu" wrote in message
news:4babc1f7.6080...@erdani.org...
> On 03/25/2010 02:52 PM, Nick Sabalausky wrote:
>>
>> I can agree mixins are a perfectly fine interim solution for anything not
>> already in the language, and for truly obscure needs (I use them all the
>> time for both
Walter Bright wrote:
bearophile wrote:
Regarding base type names I have proposed :
byte => sbyte
wchar => char16 (or shortchar)
dchar => char32 (or intchar)
Yes, we can endlessly rename keywords, but in the end, what does that
accomplish that would compensate for upending every D program in
On Fri, Mar 26, 2010 at 02:53:58AM +0100, Don wrote:
> That reply was to bearophile, who said he was minimizing the number of
> templates. But since he was using toStringNow, the code created a huge
> number of templates.
Oh sorry, I generalize too hastily!
--
Adam D. Ruppe
http://arsdnet.net
Adam D. Ruppe wrote:
On Fri, Mar 26, 2010 at 02:38:53AM +0100, Don wrote:
Do NOT use toStringNow. std.metastrings is mostly obsolete -- it
predates CTFE.
All I wanted there was a quick conversion. At first, I wrote
octal!(to!string(my_integer));
but it didn't compile...
In any case, redoing
On Fri, Mar 26, 2010 at 02:38:53AM +0100, Don wrote:
> Do NOT use toStringNow. std.metastrings is mostly obsolete -- it
> predates CTFE.
All I wanted there was a quick conversion. At first, I wrote
octal!(to!string(my_integer));
but it didn't compile...
In any case, redoing it is simple enough
On 03/25/2010 08:10 PM, Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:hogsv9$11u...@digitalmars.com...
The only choice is to support 0177 as octal or make it a syntax error. I'd
rather support them.
Supporting it means it will "silently and disastrously break code" from
anyone
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:hogsv9$11u...@digitalmars.com...
One thing is clear, though. 0177 is never going to be a decimal number in
D, because it will silently and disastrously break code translated from C.
I'm certainly fine with that, since not breaking p
bearophile wrote:
Adam D. Ruppe:
Trivial. I'll start with the code you posted on the bugzilla.
It's better to minimize the number of templates created by the code. I have
used CTFE here (not much tested):
import std.metastrings: toStringNow;
Do NOT use toStringNow. std.metastrings is most
On Thu, Mar 25, 2010 at 09:10:09PM -0400, Nick Sabalausky wrote:
> Supporting it means it will "silently and disastrously break code" from
> anyone who tries to use a leading zero
This is why I'd like them banned. Sometimes I write things like
switch(a) {
case 143: do something; break;
"Walter Bright" wrote in message
news:hogqkn$um...@digitalmars.com...
> bearophile wrote:
>> Nope, here I have suggested to turn leading zeros in syntax errors:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3837
>
> Right, but that doesn't help those who wish to use leading 0s.
I don't think
"Walter Bright" wrote in message
news:hogsv9$11u...@digitalmars.com...
>
> One thing is clear, though. 0177 is never going to be a decimal number in
> D, because it will silently and disastrously break code translated from C.
I'm certainly fine with that, since not breaking ported C code is one
Walter Bright:
>Yes, we can endlessly rename keywords, but in the end, what does that
>accomplish that would compensate for upending every D program in existence?<
I can list few pro/cons, but then the decision is not mine.
I'll close my "bug" report on the base of the answers, because this is o
On 03/25/2010 06:21 PM, Walter Bright wrote:
Ellery Newcomer wrote:
What do you think of Erlang's bit syntax if you've looked at it, or
could you if you haven't?
I know nothing about it.
I suppose you could think of it as sort of a regex-for-generic-data, but
you can use it as a pattern mat
Walter Bright:
> I admit it, I just like octal constants. I like the way they look. I don't
> feel
> an urge to kill it with fire. I'd be sad to see them go. I like disco music,
> too, despite it being definitely out of style.
OK :-)
There are other problems to fix :-)
Bye,
bearophile
Andrei Alexandrescu wrote:
On 03/25/2010 06:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Then you'll be happy to start using octal as soon as I commit it.
Haven't changed my mind about that, nor the reasons!
Haven't seen you posting the results of the grep. As "reason" has the
sam
Walter Bright Wrote:
> Adam D. Ruppe wrote:
> > The argument most often brought up for keeping octal *at all* is unix
> > filesystem permissions. They are only ever as big as four digits (AFAIK).
>
> There is one other reason: converting C code to D code. This should follow
> the
> principle of
On 03/25/2010 05:26 PM, Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:hogmgm$oc...@digitalmars.com...
Ellery Newcomer wrote:
I guess what I'm trying to say is it doesn't make sense that I can
implicitly import FooA, an external symbol, but not bar(FooA), an
external symbol defin
On 03/25/2010 06:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Then you'll be happy to start using octal as soon as I commit it.
Haven't changed my mind about that, nor the reasons!
Haven't seen you posting the results of the grep. As "reason" has the
same root as "reasoning", there
On 03/25/2010 06:12 PM, Walter Bright wrote:
bearophile wrote:
Nope, here I have suggested to turn leading zeros in syntax errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3837
Right, but that doesn't help those who wish to use leading 0s.
Why do they wish it, how often do they wish it,
Ellery Newcomer wrote:
What do you think of Erlang's bit syntax if you've looked at it, or
could you if you haven't?
I know nothing about it.
bearophile wrote:
Regarding base type names I have proposed :
byte => sbyte
wchar => char16 (or shortchar)
dchar => char32 (or intchar)
Yes, we can endlessly rename keywords, but in the end, what does that accomplish
that would compensate for upending every D program in existence?
bearophile wrote:
Nope, here I have suggested to turn leading zeros in syntax errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3837
Right, but that doesn't help those who wish to use leading 0s.
Nick Sabalausky wrote:
But now
that you're saying this I'm confused as to why that example I posted
suddenly worked when I compiled it with D2.
I haven't looked at that yet, just discussed the principle.
Andrei Alexandrescu wrote:
Then you'll be happy to start using octal as soon as I commit it.
Haven't changed my mind about that, nor the reasons!
On 03/25/2010 05:12 PM, Walter Bright wrote:
bearophile wrote:
Regarding octals (and multi-precision integer literals, and unit system
suffixes), it seems C++0x has user-defined literals :-)
http://en.wikipedia.org/wiki/C++0x#User-defined_literals (I am not
asking to
solve the D octal problem wi
"Walter Bright" wrote in message
news:hogmgm$oc...@digitalmars.com...
> Ellery Newcomer wrote:
>> I guess what I'm trying to say is it doesn't make sense that I can
>> implicitly import FooA, an external symbol, but not bar(FooA), an
>> external symbol defined on an external symbol which cannot
Walter Bright:
> Translating:
>
> 0177
>
> in C to:
>
> 0177
>
> in D will silently produce a very different result
Nope, here I have suggested to turn leading zeros in syntax errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3837
Bye,
bearophile
On Mar 26, 10 05:46, yigal chripun wrote:
while it's true that '?' has one unicode value for it, it's not true for all
sorts of diacritics and combine code-points. So your approach is to pass the
responsibility for that to the end user which in 99.% will not handle this
correctlly.
Non
Adam D. Ruppe wrote:
The argument most often brought up for keeping octal *at all* is unix
filesystem permissions. They are only ever as big as four digits (AFAIK).
There is one other reason: converting C code to D code. This should follow the
principle of "if it doesn't give a compiler error,
bearophile wrote:
Regarding octals (and multi-precision integer literals, and unit system
suffixes), it seems C++0x has user-defined literals :-)
http://en.wikipedia.org/wiki/C++0x#User-defined_literals (I am not asking to
solve the D octal problem with them.)
The C++0x syntax for them to me
Ellery Newcomer wrote:
I guess what I'm trying to say is it doesn't make sense that I can
implicitly import FooA, an external symbol, but not bar(FooA), an
external symbol defined on an external symbol which cannot be implicitly
converted to a local symbol.
And I believe it makes perfect sens
Adam D. Ruppe:
> It seems to work well.
It will need a more testing, and "negative testing" too: for example good tests
must assert that this generates an error at compile time:
octal!"_"
Bye,
bearophile
On 03/25/2010 01:08 PM, Walter Bright wrote:
There are thousands of languages out there. If I did due diligence
researching them all, I'd never finish, as new languages get created
faster than anyone could ever study them. At some point, you've gotta
pick and choose what you're going to look at
On 03/25/2010 04:32 PM, Adam D. Ruppe wrote:
On Thu, Mar 25, 2010 at 05:12:07PM -0400, bearophile wrote:
It needs many more unittests, to tests all the bounds, corner cases, etc. They
also have to test that the code actually asserts when the inputs are wrong in
various ways. This is how I test
It seems that on a conceptual level we are in complete agreement.
the difference seems to be that you want to push some things onto the user
which I think the language should provide.
Walter Bright Wrote:
> yigal chripun wrote:
> > Walter Bright Wrote:
> >
> >> Yigal Chripun wrote:
> >>> Walte
Every time I write a small number of lines of code in D2, like here, I find
what I think is a bug:
http://d.puremagic.com/issues/show_bug.cgi?id=4005
Bye,
bearophile
On 03/25/2010 02:00 PM, Walter Bright wrote:
--- a.d ---
enum FooA { fooA };
void bar(FooA x) {}
--- test.d
import a;
mixin(`
enum FooB { fooB };
void bar(FooB x) {}
`);
void test()
{
bar(FooA.fooA); //error
bar(FooB.fooB);
}
On Thu, Mar 25, 2010 at 05:12:07PM -0400, bearophile wrote:
> It needs many more unittests, to tests all the bounds, corner cases, etc.
> They also have to test that the code actually asserts when the inputs are
> wrong in various ways. This is how I test my D code.
Yeah, you're right on a few c
On Thu, Mar 25, 2010 at 04:57:00PM -0400, Adam D. Ruppe wrote:
> Run it. Boom! The tests pass.
I always post too soon!
It fails with larger numbers. The octal!(string) code is to blame; it doesn't
raise 8 to the right power on strings with length > 2.
And opPow doesn't seem to work here. So I'll
On 03/25/2010 03:57 PM, Adam D. Ruppe wrote:
On Thu, Mar 25, 2010 at 03:37:52PM -0500, Andrei Alexandrescu wrote:
Contest: define "octal" as per the blueprint above and paste it here.
Trivial. I'll start with the code you posted on the bugzilla.
Now that's what I'd call fast. bearophile made
1 - 100 of 192 matches
Mail list logo
