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'd need to use a straigh for statement.
>>
> 
> struct FloatRange {
>    float begin, end, step;
>    bool includeBegin, includeEnd;
> 
>    int opApply (int delegate (ref float) dg) {
>       whatever;
>    }
> 
>    whatever;
> }
> 
>>>  - The second issue remains: what if I want to include b but not b+ε for any ε>0?
>>
>> real a, b;
>> ...
>> for (real f = a; f <= b; update(f))
>> {
>> }
>>
>> I'd find it questionable to use ranged for with floats anyway.
>>
>     So would I. But a range of floats is useful for more than iterating over it. Think interval arithmetic for example.

Cool. I'm positive that open ranges will not prevent you from implementing such a library (and from subsequently proposing it to Phobos :o)).


Andrei

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>>>> 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.
> 
> It works for the cases where an inclusive range makes sense.

	Doesn't work with floats, which *do* make sense too...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Tue, 07 Jul 2009 14:16:14 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Robert Jacques wrote:
>> On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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 pain.
>>>
>>> Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.
>>  Suggestion 1:
>> Loft the right hand of the expression (when lofting is valid) to the size of the left hand. i.e.
>
> What does loft mean in this context?

Sorry. loft <=> up-casting. i.e.
byte => short => int => long => cent? => bigInt?

>> byte a,b,c;
>> c = a + b;  => c = a + b;
>
> Unsafe.

So is int + int or long + long. Or float + float for that matter. My point is that if a programmer is assigning a value to a byte (or short or int or long) then they are willing to accept the accociated over/under flow errors of that type.

>> short d;
>> d = a + b;  => d = cast(short) a + cast(short) b;
>
> Should work today modulo bugs.
>
>> int e, f;
>> e = a + b;  => e = cast(short) a + cast(short) b;
>
> Why cast to short? e has type int.

Opps. You're right. (I was thinking of the new rules, not my suggestion)
Should be:
e = a + b;  => e = cast(int) a + cast(int) b;

>> e = a + b + d; => e = cast(int)(cast(short) a + cast(short) b) + cast(int) d; Or e = cast(int) a + (cast(int) b + cast(int)d);
>
> I don't understand this.

Same "Opps. You're right." as above.
e = a + b + d; => e = cast(int) a + cast(int) b + cast(int) d;

>> 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 suggestion, it's not.

>> When choosing operator overloads or auto, prefer the ideal lofted interpretation (as per the new rules, but without the exception for int/long), over truncated variants. i.e.
>> auto h = a + b; => short h = cast(short) a + cast(short) b;
>
> This would yield semantics incompatible with C expressions.

How so?
The auto rule is identical to the "new rules".
The overload rule is identical to the "new rules", except when no match can be found, in which case it tries to "relax" the expression to a smaller number of bits.

>> This would also properly handled some of the corner/inconsistent cases with the current rules:
>> ubyte  i;
>> ushort j;
>> j = -i;    => j = -cast(short)i; (This currently evaluates to j = cast(short)(-i);
>
> That should not compile, sigh. Walter wouldn't listen...
>
>> And
>> a += a;
>> is equivalent to
>> a = a + a;
>
> Well not quite equivalent. In D2 they aren't. The former clarifies that you want to reassign the expression to a, and no cast is necessary. The latter would not compile if a is shorter than int.

I understand, but that dichotomy increases the cognitive load on the programmer. Also, there's the issue of
byte x;
++x;
which is defined in the spec as being equvilent to
x = x + 1;

>> and is logically consistent with
>> byte[] k,l,m;
>> m[] = k[] + l[];
>>  Essentially, instead of trying to prevent overflows, except for those from int and long, this scheme attempts to minimize the risk of overflows, including those from int (and long, once cent exists. Maybe long+long=>bigInt?)
>
> But if you close operations for types smaller than int, you end up with a scheme even more error-prone that C!

Since C (IIRC) always evaluates "x+x" in the manner most prone to causing overflows, no matter the type, a scheme can't be more error-prone than C (at the instruction level). However, it can be less consistent, which I grant can lead to higher level logic errors. (BTW, operations for types smaller than int are closed (by my non-mathy definition) in C)

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;
And if it weren't for compatibility issues, it would almost be worth it to remove them completely.

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 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 (like Python PEPs) like someone suggested a couple of days ago.
> >>I think that's a good idea. Who has the time and resources to set that up?
> >What's wrong with the Wiki?
> 
> Where's the link?

I mean the D Wiki!
http://prowiki.org/wiki4d/wiki.cgi

(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)

I think we can add a DIP (D Improvement Proposal =) section in the "Language Development" section: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Ya ni el cielo me quiere, ya ni la muerte me visita
Ya ni el sol me calienta, ya ni el viento me acaricia

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 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
>>>>> (like Python PEPs) like someone suggested a couple of days ago.
>>>> I think that's a good idea. Who has the time and resources to set that up?
>>> What's wrong with the Wiki?
>> Where's the link?
> 
> I mean the D Wiki!
> http://prowiki.org/wiki4d/wiki.cgi
> 
> (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)
> 
> I think we can add a DIP (D Improvement Proposal =) section in the
> "Language Development" section:
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

Great idea. I can only hope the technical level will be much higher than the two threads related to switch.

Andrei

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

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 end, i.e. [)
>>>  c. Exclude begin Include end, i.e. (]
>>>  d. Exclude begin Exclude end, i.e. ()
>> 
>> I'm afraid this would majorly mess with pairing of parens.
>> 
> 	I think Derek's point was to have *some* syntax to mean this, not
> necessarily the one he showed

Thank you, Jérôme. I got too frustrated to explain it well enough.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell <derek@psych.ward> 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 are very valuable)

On Tue, 07 Jul 2009 14:16:12 -0500, Andrei Alexandrescu wrote:

> Bill Baxter wrote:
>> 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>>> 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 pointer is an integer because the byte it is referring to always has an integral address value. Pointers do not point to partial bytes.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

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 Parnell
Melbourne, Australia
skype: derek.j.parnell