July 06, 2009
Walter Bright Wrote:

> のしいか (noshiika) wrote:
> > 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 9:
> > instead of
> >    case 0 .. 9:
> > 
> > With the latter notation, ranges can be easily used together with
> > commas, for example:
> >    case 0, 2 .. 4, 6 .. 9:
> > 
> > And CaseRangeStatement, being inconsistent with other syntaxes using the .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint. Shouldn't D make use of another operator to express ranges that include the endpoints as Ruby or Perl6 does?
> 
> I think this was hashed out ad nauseum in the n.g.


Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax". In the end, Andrei commented that he shouldn't involve the community in such small changes and went silent.
July 06, 2009
On Mon, 06 Jul 2009 03:13:45 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote:
>> 
>>> Derek Parnell wrote:
>>>> I'm struggling to see why the compiler cannot just disallow any signed<->unsigned implicit conversion? Is it a matter of backward compatibility again?
>>> What's the signed-ness of 5?
>> 
>> Positive. A positive number can be assigned to an 'int' if there is no size issue.
> 
> It can also be an unsigned.

Which is a positive value, right? Can you think of any unsigned value which is also negative?

>> What's the problem that I'm obviously missing?
>> 
>>> When you index a pointer, is the index signed or unsigned?
>> 
>> An index can be either. What's the problem here?
> 
> auto x = p1 - p2;
> 
> What's the type of x?

Is that what you meant by "index a pointer"?

Anyhow, it is a signed value. The difference between any two random memory addresses can be positive or negative. Whatever the 'signedness' of 'x' is, the expression "p2 + x == p1" must be true.

If p1 is 0 and p2 is uint.max then 'x' must still be able to hold
(-uint.max)

> Denis Koroskin wrote:
>>> auto x = p1 - p2;
>>>
>>> What's the type of x?
>> 
>> ptrdiff_t, signed counterpart of size_t
>
> Do you really want an error if you go:
>
> size_t y = p1 - p2;

Yes I do.

  size_t y = cast(size_t)p1 - p2; -- No error.
  ptrdiff_t y = p1 - p2; -- No error.
  size_t y = p1 - p2; -- Error.

Safety is supposed to be enhance by using D, is it not?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
July 06, 2009
On Mon, 06 Jul 2009 14:28:38 +0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Denis Koroskin wrote:
>>> auto x = p1 - p2;
>>>
>>> What's the type of x?
>>  ptrdiff_t, signed counterpart of size_t
>
> Do you really want an error if you go:
>
> size_t y = p1 - p2;
>
> ?
>

Of course, what sense does it make when p2 > p1?

I'd put an assert and mad a case explicit, if there is a size_t is so badly needed for ptr difference:

assert(p1 >= p2);
size_t y = cast(size_t)p1 - p2;
July 06, 2009
On Mon, 06 Jul 2009 14:28:38 +0400, Walter Bright
<newshound1@digitalmars.com> wrote:

> Denis Koroskin wrote:
>>> auto x = p1 - p2;
>>>
>>> What's the type of x?
>>  ptrdiff_t, signed counterpart of size_t
>
> Do you really want an error if you go:
>
> size_t y = p1 - p2;
>
> ?
>

Of course, what sense does it make when p2 > p1?

I'd put an assert and made a cast explicit, if a size_t is so badly needed for ptr difference:

assert(p1 >= p2);
size_t y = cast(size_t)p1 - p2;
July 06, 2009
Jason House:
> Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax". In the end, Andrei commented that he shouldn't involve the community in such small changes and went silent.<

He was wrong. Even very intelligent people now and then do the wrong thing.

Bye,
bearophile
July 06, 2009
What about pragmas? Aren't both rebuild/dsss and Build using them for linking? It seems to me, you would still have to parse the source files for those.



July 06, 2009
Walter Bright escribio':
> MIURA Masahiro wrote:
>> Thanks for the new release!  Are case ranges limited to 256 cases?
> 
> Yes.

Why?
July 06, 2009
のしいか (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 9:
> instead of
>    case 0 .. 9:
> 
> With the latter notation, ranges can be easily used together with commas, for example:
>    case 0, 2 .. 4, 6 .. 9:
> 
> And CaseRangeStatement, being inconsistent with other syntaxes using the .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
> Shouldn't D make use of another operator to express ranges that include the endpoints as Ruby or Perl6 does?

I agree.

I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.
July 06, 2009
I'm switching newsgroups for a bicycle-shed-color discussion.

In digitalmars.D.announce, Derek Parnell wrote:
> On Sun, 05 Jul 2009 23:35:24 -0700, Walter Bright wrote:
>> Derek Parnell wrote:
>>> But I expected the compiler to complain that an unsigned value cannot by implicitly converted to a signed value as that results in loss of *significant* bits.
>> 
>> We tried for a long time to come up with a sensible way to deal with the signed/unsigned dichotomy. We finally gave that up as unworkable. Instead, we opted for a method of significant bits, *not* how those bits are interpreted. -6 and 250 are the same bits in byte and ubyte, the difference is interpretation.
> 
> I am disappointed. I hope that you haven't stopped working on a solution to this though, as allowing D to silently permit bugs it could prevent is not something we are hoping for.

Seems to me there are two different concepts that might be separable: fixed-precision integers and machine words.  Machine words are raw data: bits, bytes, words (of various sizes).  Then there are interpretations of these, as signed/unsigned ints, as pointers, as floating-point data, &c.  Might it be reasonable to distinguish raw words from the integral types?

I.e., on x86-32 there might be the types byte = word8, short word = word16, word = word32, long word = word64.  These are neither signed nor unsigned, e.g., a word8 can be assigned a value in the range -128--255, but you cannot say if(word1 < word2).  Build std.bitfield on these. Disallow conversions between sizes without casts, and provide distinct zero-fill & sign-extension casts.

Distinct from these are the integral types: (u)int[8. 16, 32, 64, ...].
 Allow implicit conversion from word to integral types, and give integer
literals a wordn type.  (A warning in cases like uint x = -5 or int8 y =
350 might be handy, though.)  Now there can be room to tighten the rules
for signed/unsigned conversions.

Another possible use for this might be on a machine that can optionally trap on integer overflow:  Define overflow on (u)intn to be a -- possibly untrapped -- run-time error, but explicitly *allow* overflow in arithmetic on wordn types.  (Otherwise, only bitwise operators have much meaning on the wordn types.)

—Joel Salomon
July 06, 2009
Walter Bright Wrote:
> The deps thing comes from the LDC group. They've been relying on it as-is, so they'd need to agree on any changes.

Actually, it's from Tomasz' xfBuild http://wiki.team0xf.com/index.php?n=Tools.XfBuild . As it is intended as a generally useful dependency format though, I'm sure he'll open for suggestions.