March 25, 2010
grauzone:
> For your information, programming in Delphi (modern Pascal dialect) was quite a joy.

I agree, D and C# are better, but Delphi and FreePascal are not bad languages to use.


> You must have had only experience with early Pascal dialects... and then never looked at anything that smelled like Pascal...

From the first Pascals and the currently available FreePascal there's a night-day difference. It has OOP, templates, low level constructs, a standard library, good strings, etc. And your binaries are tiny. You can't judge FreePascal from the ancient Pascals.

Bye,
bearophile
March 25, 2010
Walter Bright Wrote:

> yigal chripun wrote:
> > here's a simple version without casts: int toString(dchar[] arr) { int temp =
> > 0; for (int i = 0; i < arr.length; i++) { int digit = arr[i].valueOf - 30; //
> > * if (digit < 0 || digit > 9) break; temp += 10^^i * digit; } return temp; }
> > 
> > [*] Assume that dchar has a valueOf property that returns the value.
> > 
> > where's that mess of casts you mention?
> 
> In Pascal, you'd have type errors all over the place. First off, you cannot do
> arithmetic on characters. You have to cast them to integers (with the ORD(c)
> construction).
> 

> > Pascal is hardly the only language without excplicit casts.
> 
> Pascal has explicit casts. The integer to character one is CHR(i), the character to integer is ORD(c).
> 

I meant implicit, sorry about that. The pascal way is definitely the correct way. what's the semantics in your opinion of ('f' + 3) ? what about ('?' + 4)? making such arithmetic valid is wrong.
I'm sure that the first Pascal versions had problems which caused you to ditch that language (they where fixed later). I doubt it though that this had a large impact on Pascal's problems.

> 
> > ML is also
> > properly strongly typed and is an awesome language to use.
> 
> I don't know enough about ML to comment intelligently on it.
> 
> 
> > The fact that D has 12 integral types is a bad design, why do we need so many built in types? to me this clearly shows a need to refactor this aspect of D.
> 
> Which would you get rid of? (13, I forgot bool!)
> 
> bool
> byte
> ubyte
> short
> ushort
> int
> uint
> long
> ulong
> char
> wchar
> dchar
> enum

you forgot the cent and ucent types and what about 256bit types?

Here's How I'd want it designed:
First of, a Boolean type should not belong to this list at all and shouldn't be treated as a numeric type.
Second, there really only few use-cases that are relevant

signed types for representing numbers:
1) unlimited integral type - int
2) limited integral type  - int!(bits), e.g. int!16, int!8, etc..
3) user defined range: e.g. [0, infinity) for positive numbers, etc..

unsigned bit-packs:
4) bits!(size), e.g. bits!8, bits!32, etc..

of course you can define useful aliases, e.g.
alias bits!8 Byte;
alias bits!16 Word;
..
or you can define the aliases per the architecture, so that Word above will be defined for the current arch (I don't know what's the native word size on say ARM and other platforms)

char and relatives should be for text only per Unicode, (perhaps a better name is code-point). for other encodings use the above bit packs, e.g.
alias bits!7 Ascii;
alias bits!8 ExtendedAscii;
etc..

enum should be an enumeration type. You can find an excellent strongly-typed  design in Java 5.0
March 25, 2010
On 03/25/2010 06:58 AM, bearophile wrote:
> Walter Bright:
>> Disabling implicit integral conversions would make it unbearable to use.<
>
> Implicit conversion from signed to unsigned is too much unsafe (if you don't have integer overflows).
> C# can teach us two lessons on this. C# has disabled some implicit conversions and keeps other of them.

The problem is it asks you to insert casts all too often. I think the value range propagation is a principled and correct solution to that problem.

Andrei

March 25, 2010
On 03/24/2010 11:40 PM, Walter Bright wrote:
> Nick Sabalausky wrote:
>>> In D1, is there any reason I should be getting an error on this?:
>>>
>>> // module A:
>>> enum FooA { fooA };
>>> void bar(FooA x) {}
>>>
>>> // module B:
>>> import A;
>>> enum FooB { fooB };
>>> void bar(FooB x) {}
>>>
>>> bar(FooB.fooB); // Error: A.bar conflicts with B.bar (WTF?)
>
> ------- a.d -------------------
> enum FooA { fooA };
> void bar(FooA x) {}
> ------- test.d ----------------
> import a;
> enum FooB { fooB };
> void bar(FooB x) {}
>
> void test()
> {
> bar(FooB.fooB);
> }
> ------------------------------
>
> with:
>
> dmd test
>
> I do not get an error with either D1 or D2. So, if you are getting an
> error, how is your code different?

------- 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);
}
------------------------------


------- a.d -------------------
enum FooA { fooA };
void bar(FooA x) {}
------- test.d ----------------
import a;
alias a.bar bar;
mixin(`
enum FooB { fooB };
void bar(FooB x) {}
`);

void test()
{
    bar(FooA.fooA);
    bar(FooB.fooB); //error
}
------------------------------

Somewhat OT: I wish enums had something analogous to struct's tupleof, or some way to enumerate the values of the enum, and maybe their names too. Do they?
March 25, 2010
Andrei Alexandrescu:
> The problem is it asks you to insert casts all too often. I think the value range propagation is a principled and correct solution to that problem.

In bugzilla I have asked to disable the implicit conversion enum => base type in an equality test, see: http://d.puremagic.com/issues/show_bug.cgi?id=3999

In bugzilla I have never asked to disable implicit signed => unsigned casts, I am able to see they are two quite different situations.

I think the implicit conversions from enum => base types are uncommon enough, so they can't introduce too many casts.

If Walter doesn't agree with me (and few other people here) then there's no point in keeping bug 3999 open, it can be closed. Because it's better to fix/change similar things now, when the D2 language is not diffused yet. Later such changes are harder to do.

In bugzilla there are few other things that deserve a similar look. Those changes can't be done all at the same time, but the decision can be taken in a short enough time, and it's better to think about them now.

Bye and thank you for your attention,
bearophile
March 25, 2010
Ellery Newcomer:
> Somewhat OT: I wish enums had something analogous to struct's tupleof, or some way to enumerate the values of the enum, and maybe their names too. Do they?

D2 now gives you the tools to do that, even if it's bad looking code:

import std.stdio: writeln;
enum Foo { Aa, Bb, Cc }
void main() {
    foreach (name; __traits(allMembers, Foo))
        writeln(name, " ", mixin("cast(int)Foo." ~ name));
}


Output:
Aa 0
Bb 1
Cc 2

Bye,
bearophile
March 25, 2010
On 03/25/2010 11:17 AM, bearophile wrote:
> Andrei Alexandrescu:
>> The problem is it asks you to insert casts all too often. I think the
>> value range propagation is a principled and correct solution to that
>> problem.
>
> In bugzilla I have asked to disable the implicit conversion enum =>  base type in an equality test, see:
> http://d.puremagic.com/issues/show_bug.cgi?id=3999
>
> In bugzilla I have never asked to disable implicit signed =>  unsigned casts, I am able to see they are two quite different situations.
>
> I think the implicit conversions from enum =>  base types are uncommon enough, so they can't introduce too many casts.
>
> If Walter doesn't agree with me (and few other people here) then there's no point in keeping bug 3999 open, it can be closed. Because it's better to fix/change similar things now, when the D2 language is not diffused yet. Later such changes are harder to do.
>
> In bugzilla there are few other things that deserve a similar look. Those changes can't be done all at the same time, but the decision can be taken in a short enough time, and it's better to think about them now.
>
> Bye and thank you for your attention,
> bearophile

I think defining a integral() function that gives the value of the enum as an appropriately-typed integral number wouldn't harm.

Andrei
March 25, 2010
Andrei Alexandrescu wrote:
> On 03/25/2010 11:17 AM, bearophile wrote:
>> Andrei Alexandrescu:
>>> The problem is it asks you to insert casts all too often. I think the
>>> value range propagation is a principled and correct solution to that
>>> problem.
>>
>> In bugzilla I have asked to disable the implicit conversion enum =>  base type in an equality test, see:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3999
>>
>> In bugzilla I have never asked to disable implicit signed =>  unsigned casts, I am able to see they are two quite different situations.
>>
>> I think the implicit conversions from enum =>  base types are uncommon enough, so they can't introduce too many casts.
>>
>> If Walter doesn't agree with me (and few other people here) then there's no point in keeping bug 3999 open, it can be closed. Because it's better to fix/change similar things now, when the D2 language is not diffused yet. Later such changes are harder to do.
>>
>> In bugzilla there are few other things that deserve a similar look. Those changes can't be done all at the same time, but the decision can be taken in a short enough time, and it's better to think about them now.
>>
>> Bye and thank you for your attention,
>> bearophile
> 
> I think defining a integral() function that gives the value of the enum as an appropriately-typed integral number wouldn't harm.
> 
> Andrei

Why not let to!int() do this?

-Lars
March 25, 2010
Lars T. Kyllingstad:
> Why not let to!int() do this?

Because if the enum is for example:
enum ulong Foo { ...

You are casting an ulong to int and you risk losing bits of information. That's why Andrei has suggested a conversion template function, because it can (I don't know how) find the correct base type and cast the enum to it. Andrei is sometimes one step forward.

Bye,
bearophile
March 25, 2010
On 03/25/2010 11:57 AM, Lars T. Kyllingstad wrote:
> Andrei Alexandrescu wrote:
>> On 03/25/2010 11:17 AM, bearophile wrote:
>>> Andrei Alexandrescu:
>>>> The problem is it asks you to insert casts all too often. I think the
>>>> value range propagation is a principled and correct solution to that
>>>> problem.
>>>
>>> In bugzilla I have asked to disable the implicit conversion enum =>
>>> base type in an equality test, see:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3999
>>>
>>> In bugzilla I have never asked to disable implicit signed => unsigned
>>> casts, I am able to see they are two quite different situations.
>>>
>>> I think the implicit conversions from enum => base types are uncommon
>>> enough, so they can't introduce too many casts.
>>>
>>> If Walter doesn't agree with me (and few other people here) then
>>> there's no point in keeping bug 3999 open, it can be closed. Because
>>> it's better to fix/change similar things now, when the D2 language is
>>> not diffused yet. Later such changes are harder to do.
>>>
>>> In bugzilla there are few other things that deserve a similar look.
>>> Those changes can't be done all at the same time, but the decision
>>> can be taken in a short enough time, and it's better to think about
>>> them now.
>>>
>>> Bye and thank you for your attention,
>>> bearophile
>>
>> I think defining a integral() function that gives the value of the
>> enum as an appropriately-typed integral number wouldn't harm.
>>
>> Andrei
>
> Why not let to!int() do this?
>
> -Lars

Because an enum that uses long as a base will not be converted. integral() would automatically deduce and return the appropriate base type.

Andrei