Steven Schveighoffer:
> Does this compile:
>
> class C {}
>
> ubyte foo(C n)
> {
>return true ? 255 : n;
> }
>
> (don't have the latest compiler installed yet, so I couldn't check it
> myself)
It doesn't compile (DMD v2.031):
temp.d(5): Error: incompatible types for ((255) ? (n)): 'int' a
On Fri, 17 Jul 2009 09:46:11 -0400, Don wrote:
Steven Schveighoffer wrote:
On Fri, 17 Jul 2009 08:08:23 -0400, Don wrote:
In this case, I think bearophile's right: it's just a problem with
range propagation of the ?: operator. I think the compiler should be
required to do the semantics a
Steven Schveighoffer wrote:
On Fri, 17 Jul 2009 08:08:23 -0400, Don wrote:
In this case, I think bearophile's right: it's just a problem with
range propagation of the ?: operator. I think the compiler should be
required to do the semantics analysis for single expressions. Not
more, not less.
On Fri, 17 Jul 2009 08:08:23 -0400, Don wrote:
In this case, I think bearophile's right: it's just a problem with range
propagation of the ?: operator. I think the compiler should be required
to do the semantics analysis for single expressions. Not more, not less.
Why? What is the benefit
BCS wrote:
Reply to bearophile,
John C:
Did you not read the change log?
"Implicit integral conversions that could result in loss of
significant bits are no longer allowed."
This was the code:
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
That last n is guaranteed to fit inside an ubyte
I
BCS wrote:
Reply to bearophile,
John C:
Did you not read the change log?
"Implicit integral conversions that could result in loss of
significant bits are no longer allowed."
This was the code:
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
That last n is guaranteed to fit inside an ubyte (ye
On Thu, Jul 16, 2009 at 6:43 PM, Jason House wrote:
> bearophile Wrote:
>
>> I'm playing with the new D2 a bit, this comes from some real D1 code:
>>
>> void main(string[] args) {
>> int n = args.length;
>> ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
>> }
>>
>> At compile-time the compil
bearophile Wrote:
> I'm playing with the new D2 a bit, this comes from some real D1 code:
>
> void main(string[] args) {
> int n = args.length;
> ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
> }
>
> At compile-time the compiler says:
> temp.d(3): Error: cannot implicitly convert expres
Steven Schveighoffer wrote:
On Thu, 16 Jul 2009 08:49:14 -0400, bearophile
wrote:
I'm playing with the new D2 a bit, this comes from some real D1 code:
void main(string[] args) {
int n = args.length;
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
}
At compile-time the compiler says:
Reply to bearophile,
John C:
Did you not read the change log?
"Implicit integral conversions that could result in loss of
significant bits are no longer allowed."
This was the code:
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
That last n is guaranteed to fit inside an ubyte (yes, I underst
On Thu, 16 Jul 2009 08:49:14 -0400, bearophile
wrote:
I'm playing with the new D2 a bit, this comes from some real D1 code:
void main(string[] args) {
int n = args.length;
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
}
At compile-time the compiler says:
temp.d(3): Error: cannot im
John C:
> Did you not read the change log?
> "Implicit integral conversions that could result in loss of significant bits
> are no longer allowed."
This was the code:
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
That last n is guaranteed to fit inside an ubyte (yes, I understand the
compiler
bearophile Wrote:
> I'm playing with the new D2 a bit, this comes from some real D1 code:
>
> void main(string[] args) {
> int n = args.length;
> ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
> }
>
> At compile-time the compiler says:
> temp.d(3): Error: cannot implicitly convert expres
I'm playing with the new D2 a bit, this comes from some real D1 code:
void main(string[] args) {
int n = args.length;
ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
}
At compile-time the compiler says:
temp.d(3): Error: cannot implicitly convert expression (n <= 0 ? 0 : n >= 255 ?
255 :
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright
wrote:
>Something for everyone here.
>
>
>http://www.digitalmars.com/d/1.0/changelog.html
>http://ftp.digitalmars.com/dmd.1.046.zip
>
>
>http://www.digitalmars.com/d/2.0/changelog.html
>http://ftp.digitalmars.com/dmd.2.031.zip
Nice release. Thank
Leandro Lucarella wrote:
Walter Bright, el 5 de julio a las 22:05 me escribiste:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
I
Andrei Alexandrescu wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
That's really cool. But I don't think that's actually happening (Or
are these the bugs you're talking about?):
byte x,y;
short z;
z = x+y; // E
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax
form
Walter Bright wrote:
grauzone wrote:
I oriented this on the syntax of array slices. Which work that way.
Not inconsistent at all. It's also consistent with foreach(_; x..y).
It would look consistent, but it would behave very differently. x..y for
foreach and slices is exclusive of the y, whil
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
P.S. With the help of a dictionary I think I figured most of this joke:
MP: Cómo está, estimado Bellini? B: Muy bien, Mario, astrologando.
MP: Qué tengo? B: Un balcón-terraza.
MP: No, en mi mano, B
Walter Bright wrote:
Andrei Alexandrescu wrote:
P.S. With the help of a dictionary I think I figured most of this joke:
MP: Cómo está, estimado Bellini? B: Muy bien, Mario, astrologando.
MP: Qué tengo? B: Un balcón-terraza.
MP: No, en mi mano, Bellini... B: Un secarrop
Andrei Alexandrescu wrote:
P.S. With the help of a dictionary I think I figured most of this joke:
MP: Cómo está, estimado Bellini? B: Muy bien, Mario, astrologando.
MP: Qué tengo? B: Un balcón-terraza.
MP: No, en mi mano, Bellini... B: Un secarropas!
MP: No, escuche bi
Leandro Lucarella wrote:
I incidentally went through all the D2 bug reports that had being fixed in
this release and I was really surprised about how much of them had patches
by Don (the vast majority!).
Don's an awesome contributor. I and the rest of the D community are very
much indebted to
Andrei Alexandrescu, el 8 de julio a las 11:46 me escribiste:
I'm sorry about the spanish taglines, they are selected randomly =)
And most (in spanish) are pretty local (argentine) jokes.
> P.S. With the help of a dictionary I think I figured most of this joke:
>
> MP: Cómo está, estimado Bell
Leandro Lucarella wrote:
Walter Bright, el 5 de julio a las 22:05 me escribiste:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
I
Walter Bright, el 5 de julio a las 22:05 me escribiste:
> Something for everyone here.
>
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.046.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.031.zip
I incidental
Jesse Phillips, el 8 de julio a las 01:27 me escribiste:
> On Tue, 07 Jul 2009 18:43:41 -0300, Leandro Lucarella wrote:
>
> >
> > (BTW, nice job with the Wiki for whoever did it, I don't remember who
> > was putting a lot of work on improving the Wiki, but it's really much
> > better organized n
"Lionello Lunesu" wrote in message
news:h30vss$pm...@digitalmars.com...
>
> Walter, since the lib/include folders were split according to OS, the dmd2
> zip consistently has an extensionless "lib" file in the dmd2 folder.
It's also in D1.
On Wed, 08 Jul 2009 00:08:13 -0400, Brad Roberts
wrote:
Walter Bright wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
wrote:
Robert Jacques wrote:
(Caveat: most 32-bit compilers probably defaulted integer to int,
though 64-bit compilers are probably default
Walter Bright wrote:
> Robert Jacques wrote:
>> On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
>> wrote:
>>> Robert Jacques wrote:
(Caveat: most 32-bit compilers probably defaulted integer to int,
though 64-bit compilers are probably defaulting integer to long.)
>>>
>>> All 32 bit C c
Robert Jacques wrote:
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
wrote:
Robert Jacques wrote:
(Caveat: most 32-bit compilers probably defaulted integer to int,
though 64-bit compilers are probably defaulting integer to long.)
All 32 bit C compilers defaulted int to 32 bits. 64 bit C c
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
wrote:
Robert Jacques wrote:
(Caveat: most 32-bit compilers probably defaulted integer to int,
though 64-bit compilers are probably defaulting integer to long.)
All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are
settin
Thanks.
Robert Jacques wrote:
So by the spec (and please correct me if I'm reading this wrong)
g = e + f => g = cast(long)( cast(integer)e + cast(integer)f );
where integer is unbounded in bits (and therefore has no overflow)
therefore
g = e + f; => d = cast(long) e + cast(long) f;
is more in keepin
On Tue, 07 Jul 2009 11:05:31 -0400, bearophile wrote:
> KennyTM~ Wrote:
>> Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx .
>
> That compromise design looks good to be adopted by D too :-)
>
> Bye,
> bearophile
For which we have, case 1, 2, 3: writeln("I believe");
"Walter Bright" wrote in message
news:h2s0me$30f...@digitalmars.com...
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
Great rele
On Tue, 07 Jul 2009 21:05:45 -0400, Walter Bright
wrote:
Andrei Alexandrescu wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior
On Tue, 07 Jul 2009 18:26:36 -0700, Walter Bright wrote:
> All the messages from the dawn of time are online and available at
> http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable
> from the search box in the upper left.
Okaaayy ... I see that this (checking for integer ove
Robert Jacques wrote:
On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested t
On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens
Andrei Alexandrescu wrote:
You can implement that as a library. In fact I wanted to do it for
Phobos for a long time. I've discussed it in this group too (to an
unusual consensus), but I forgot the thread's title and stupid
Thunderbird "download 500 headers at a time forever even long after hav
On Tue, 07 Jul 2009 18:43:41 -0300, Leandro Lucarella wrote:
>
> (BTW, nice job with the Wiki for whoever did it, I don't remember who
> was putting a lot of work on improving the Wiki, but it's really much
> better organized now)
Hi, thanks.
> I think we can add a DIP (D Improvement Proposal
On Tue, 07 Jul 2009 20:13:40 -0500, Andrei Alexandrescu wrote:
> Derek Parnell wrote:
>> Here is where I propose having a signal to the compiler about which
>> specific variables I'm worried about, and if I code an assignment to one of
>> these that can potentially overflow, then the compiler must
Robert Jacques wrote:
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior according to the new
Derek Parnell wrote:
Here is where I propose having a signal to the compiler about which
specific variables I'm worried about, and if I code an assignment to one of
these that can potentially overflow, then the compiler must issue a
message.
You can implement that as a library. In fact I wante
Andrei Alexandrescu, el 7 de julio a las 16:54 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 7 de julio a las 15:12 me escribiste:
> >>Leandro Lucarella wrote:
> >>>Andrei Alexandrescu, el 7 de julio a las 10:56 me escribiste:
> Leandro Lucarella wrote:
> >This see
Andrei Alexandrescu wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior according to the new rules and
not a bug. In the new rules i
On Tue, 07 Jul 2009 19:39:55 -0500, Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> "bearophile" wrote in message
>> news:h3093m$2mu...@digitalmars.com...
>>> Before adding a feature X let's discuss them, ... If not enough people
>>> like a solution then let's not add it.
>>
>> Somethin
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior according to the new rules and
not a bug. In the new rules int is special, in this sugge
Nick Sabalausky wrote:
"bearophile" wrote in message
news:h3093m$2mu...@digitalmars.com...
Before adding a feature X let's discuss them, ... If not enough people
like a solution then let's not add it.
Something like that was attempted once before. Andrei didn't like what we
had to say, got h
On Tue, 07 Jul 2009 18:10:24 -0400, Robert Jacques wrote:
> On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell wrote:
>
>> On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:
>>
>>
>>> Well, how often does everyone else use bytes?
>>
>> Cryptography, in my case.
>>
>
> Cool. If you don't m
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h30907$2lk...@digitalmars.com...
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h2vprn$1t7...@digitalmars.com...
This is a different beast. We simply couldn't devise a satisfactory
scheme within the constr
"Andrei Alexandrescu" wrote in message
news:h30907$2lk...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:h2vprn$1t7...@digitalmars.com...
>>> This is a different beast. We simply couldn't devise a satisfactory
>>> scheme within the constraints we
"bearophile" wrote in message
news:h3093m$2mu...@digitalmars.com...
> Before adding a feature X let's discuss them, ... If not enough people
> like a solution then let's not add it.
Something like that was attempted once before. Andrei didn't like what we
had to say, got huffy, and withdrew fr
Robert Jacques wrote:
The new rules are definitely an improvement over C, but they make
byte/ubyte/short/ushort second class citizens, because practically every
assignment requires a cast:
byte a,b,c;
c = cast(byte) a + b;
They've always been second class citizens, as their types keep getting
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
I assume then that you've looked at something lke C#'s
checked/unchecked scheme and someone's (I forget who) idea of
expanding that to something like unchecked(overflow, sign)? What was
wrong with those sorts of things?
An unchecked-based ap
On Tue, 07 Jul 2009 21:20:42 +0200, "Jérôme M. Berger" wrote:
> Andrei Alexandrescu wrote:
>> Jérôme M. Berger wrote:
>>> Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
> Andrei Alexandrescu wrote:
>> Derek Parnell wrote:
>>> It seems that D would benefit from having a standar
On Tue, 07 Jul 2009 13:16:14 -0500, Andrei Alexandrescu wrote:
> Safe D is concerned with memory safety only.
That's a pity. Maybe it should be renamed to Partially-Safe D, or Safe-ish
D, Memory-Safe D, or ... well you get the point. Could be misleading for
the great unwashed.
--
Derek Parnel
On Tue, 07 Jul 2009 14:16:12 -0500, Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> 2009/7/7 Andrei Alexandrescu :
>>> I think Walter's message really rendered the whole discussion moot. Post of
>>> the year:
>>>
>>> =
>>> I like:
>>>
>>> a .. b+1
>>>
>>> to mean inclu
On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell wrote:
On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:
Well, how often does everyone else use bytes?
Cryptography, in my case.
Cool. If you don't mind, what's you're take new rules? (As different use
cases and points of view
On Tue, 07 Jul 2009 20:13:45 +0200, "Jérôme M. Berger" wrote:
> Andrei Alexandrescu wrote:
>> Derek Parnell wrote:
>>> It seems that D would benefit from having a standard syntax format for
>>> expressing various range sets;
>>> a. Include begin Include end, i.e. []
>>> b. Include begin Exclude
On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:
> Well, how often does everyone else use bytes?
Cryptography, in my case.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Leandro Lucarella wrote:
Andrei Alexandrescu, el 7 de julio a las 15:12 me escribiste:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 7 de julio a las 10:56 me escribiste:
Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG bef
Andrei Alexandrescu, el 7 de julio a las 15:12 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 7 de julio a las 10:56 me escribiste:
> >>Leandro Lucarella wrote:
> >>>This seems nice. I think it would be nice if this kind of things are
> >>>commented in the NG before a compil
On Tue, 07 Jul 2009 14:16:14 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Andrei, I have a short vector template (think vec!(byte,3), etc)
where I've had to wrap the majority lines of code i
Walter Bright wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu :
I think Walter's message really rendered the whole discussion moot.
Post of
the year:
=
I like:
a .. b+1
to mean inclusive range.
=
Not ever
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
- A floating point range should allow you to specify the iteration
step, or else it should allow you to iterate through all numbers that
can be represented with the corresponding precision;
We don't have that, so you
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
- A floating point range should allow you to specify the iteration
step, or else it should allow you to iterate through all numbers that
can be represented with the corresponding precision;
We don't have that, so you'd need to use a straigh
Leandro Lucarella wrote:
Andrei Alexandrescu, el 7 de julio a las 10:56 me escribiste:
Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG before a compiler release, to allow community input
and discussion.
Yup, that's what happene
bearophile wrote:
Andrei Alexandrescu:
How often did you encounter that issue?
Please, let's be serious, and let's stop adding special cases to D,
or they will kill the language.
Don't get me going about what could kill the language.
Lately I have seen too many special
cases. For example t
Andrei Alexandrescu, el 7 de julio a las 10:56 me escribiste:
> Leandro Lucarella wrote:
> >This seems nice. I think it would be nice if this kind of things are
> >commented in the NG before a compiler release, to allow community input
> >and discussion.
>
> Yup, that's what happened to case :o).
Andrei Alexandrescu:
> How often did you encounter that issue?
Please, let's be serious, and let's stop adding special cases to D, or they
will kill the language.
Lately I have seen too many special cases.
For example the current design of the rules of integral seems bad. It has bugs
and special
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h2vprn$1t7...@digitalmars.com...
This is a different beast. We simply couldn't devise a satisfactory scheme
within the constraints we have. No simple solution we could think of has
worked, nor have a number of sophisticated sol
Jérôme M. Berger wrote:
- A floating point range should allow you to specify the iteration
step, or else it should allow you to iterate through all numbers that
can be represented with the corresponding precision;
We don't have that, so you'd need to use a straigh for statement.
- The secon
"Andrei Alexandrescu" wrote in message
news:h2vprn$1t7...@digitalmars.com...
>
> This is a different beast. We simply couldn't devise a satisfactory scheme
> within the constraints we have. No simple solution we could think of has
> worked, nor have a number of sophisticated solutions. Ideas wo
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax
format for
expressing variou
Andrei Alexandrescu wrote:
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu :
I think Walter's message really rendered the whole discussion moot.
Post of
the year:
=
I like:
a .. b+1
to mean inclusive range.
=
Not everything is an integer.
Leandro Lucarella wrote:
Andrei Alexandrescu, el 7 de julio a las 13:18 me escribiste:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
a. Include begin Include end, i
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax
format for
expressing various range sets;
a. Include be
Andrei Alexandrescu, el 7 de julio a las 13:18 me escribiste:
> Jérôme M. Berger wrote:
> >Andrei Alexandrescu wrote:
> >>Derek Parnell wrote:
> >>>It seems that D would benefit from having a standard syntax format for
> >>>expressing various range sets;
> >>> a. Include begin Include end, i.e. []
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format
for
expressing various range sets;
a. Include begin Include end, i.e. []
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
a. Include begin Include end, i.e. []
b. Include begin Exclude end
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu :
I think Walter's message really rendered the whole discussion moot. Post of
the year:
=
I like:
a .. b+1
to mean inclusive range.
=
Not everything is an integer.
Works with pointers too.
A
2009/7/7 Andrei Alexandrescu :
> I think Walter's message really rendered the whole discussion moot. Post of
> the year:
>
> =
> I like:
>
> a .. b+1
>
> to mean inclusive range.
> =
Not everything is an integer.
--bb
Andrei Alexandrescu:
> Safe D is concerned with memory safety only.
And hopefully you will understand that is wrong :-)
Bye,
bearophile
Andrei Alexandrescu:
> I think Walter's message really rendered the whole discussion moot. Post
> of the year:
> =
> I like:
> a .. b+1
> to mean inclusive range.
That was my preferred solution, starting from months ago.
Bye,
bearophile
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
a. Include begin Include end, i.e. []
b. Include begin Exclude end, i.e. [)
c. Exclude beg
Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
BTW: this means byte and short are not closed under arithmetic
operations, which drastically limit their usefulness.
I think they shouldn't be closed because they overflow for relativel
Robert Jacques wrote:
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Andrei, I have a short vector template (think vec!(byte,3), etc)
where I've had to wrap the majority lines of code in cast(T)( ... ),
because I support bytes and shorts. I find that bot
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
a. Include begin Include end, i.e. []
b. Include begin Exclude end, i.e. [)
c. Exclude begin Include end, i.e. (]
d.
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
a. Include begin Include end, i.e. []
b. Include begin Exclude end, i.e. [)
c. Exclude begin Include end, i.e. (]
d. Exclude begin Exclude end
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Andrei, I have a short vector template (think vec!(byte,3), etc) where
I've had to wrap the majority lines of code in cast(T)( ... ), because
I support bytes and shorts. I find that both a kludge and a pai
On Tue, 07 Jul 2009 08:53:49 +0200, Lars T. Kyllingstad wrote:
> Ary Borenszweig wrote:
>> のしいか (noshiika) escribió:
>>> Thank you for the great work, Walter and all the other contributors.
>>>
>>> But I am a bit disappointed with the CaseRangeStatement syntax. Why is
>>> it
>>>case 0: .. case
On Tue, Jul 7, 2009 at 11:33 AM, Andrei
Alexandrescu wrote:
>
> Well 32-bit architectures may be a historical relic but I don't think 32-bit
> integers are. And I think it would be too disruptive a change to promote
> results of arithmetic operation between integers to long.
>
> ...
>
> This is a d
Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG before a compiler release, to allow community input
and discussion.
Yup, that's what happened to case :o).
I think this kind of things are the ones that deserves some kind of RFC
Andrei Alexandrescu, el 7 de julio a las 00:48 me escribiste:
> Robert Jacques wrote:
> >On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright
> >
> >wrote:
> >>Something for everyone here.
> >>
> >>
> >>http://www.digitalmars.com/d/1.0/changelog.html
> >>http://ftp.digitalmars.com/dmd.1.046.zip
> >
Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
That's really cool. But I don't think that's actually happening (Or
are these the bugs you're talking about?):
byte x,y;
short z;
z = x+y; // Error: cannot implicitly conv
Jarrett Billingsley wrote:
The only thing is: why doesn't _this_ fail, then?
int x, y, z;
z = x + y;
I'm sure it's out of convenience, but what about in ten, fifteen years
when 32-bit architectures are a historical relic and there's still
this hole in the type system?
Well 32-bit architecture
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
That's really cool. But I don't think that's actually happening (Or
are these the bugs you're talking about?):
byte x,y;
short z;
z = x+y; // Error: cannot implicitly convert expression
(cas
1 - 100 of 225 matches
Mail list logo
