headers
bearophile | 1 Sep 2010 01:19
Picon

Bug 3999 and 4261

Probably each of the ~25 bugs of the short list I have shown here recently need a bit of discussion (also
because some of them are little breaking changes over current DMD and/or TDPL). Even if some of them may
need to wait in Bugzilla for two years, it's positive to discuss them already. But you can't discuss all of
them at the same time.

This is one of them, chosen almost randomly, because it was recently commented by Andrej Mitrovic:
http://d.puremagic.com/issues/show_bug.cgi?id=4261
It's related to:
http://d.puremagic.com/issues/show_bug.cgi?id=3999
http://d.puremagic.com/issues/show_bug.cgi?id=3308

I think bug 3999 shows the root of the situation, so I focus on it (indeed bug 4261 was not in that short list).
In C++0x Foo::V1 == 10 is a compile error, enum and int can't be compared (don't miss the 'class' there):

enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}

test.cpp: In function 'int main()':
test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
test.cpp:3: note: candidates are: operator==(int, int) <built-in>

The point of the change suggested in bug 3999 is that this looks good to be adopted in D too. Enumerated
sequences in my opinion are less bug-prone if they are true distinct types.

--------------------

Note: despite in D unfortuntately constants and enumerated values share the same keyword, here I am not
talking about constants like this one:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nick Sabalausky | 1 Sep 2010 01:17

Re: std.mixins

"dsimcha" <dsimcha <at> yahoo.com> wrote in message 
news:i5jtdn$1g4t$1 <at> digitalmars.com...
>
> Isn't this a core language feature that's in the spec but is only 
> currently
> implemented for arrays?  I thought eventually uniform function call syntax 
> was
> coming for classes and structs, too.

I've been really wishing for a long time that would actually happen. It's 
annoying enough not to be able to do it for most types, but then the fact 
that it's special-cased at all is a bit of a bizarre inconsistency.
Permalink | Reply | 1 comment |
headers
bearophile | 1 Sep 2010 01:32
Picon

Re: Bug 3999 and 4261

A way to tell them apart is the presence of the EnumTag, if it's present, then the enum is a new type:

enum V1 = 10;
enum { V2 = 20 }
enum Foo { V3 }
void main() {
    assert(V1 == 10);    // OK
    assert(V2 == 20);    // OK
    assert(Foo.V3 == 0); // ERROR, type mismatch
}

Bye,
bearophile
Permalink | Reply | 1 comment |
headers
Daniel Gibson | 1 Sep 2010 01:45
Picon
Gravatar

Re: Bug 3999 and 4261

bearophile schrieb:
> A way to tell them apart is the presence of the EnumTag, if it's present, then the enum is a new type:
> 
> enum V1 = 10;
> enum { V2 = 20 }
> enum Foo { V3 }
> void main() {
>     assert(V1 == 10);    // OK
>     assert(V2 == 20);    // OK
>     assert(Foo.V3 == 0); // ERROR, type mismatch
> }
> 
> Bye,
> bearophile

I sometimes find it convenient to just treat those values as integers, 
e.g. when reading/writing them with a stream (to a file, to some other 
process with SocketStream, ...).
Like
---
int x;
stream.read(x); // btw: this often sucks - why not x = stream.readInt()?
if(x == MyEnum.DIE)
	return 0;
else if(x == MyEnum.CALLFOO)
	foo(x);
---
or something like that (switch() might be better, but whatever).

Also treating named and unnamed enums differently seems inconsistent to me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Walter Bright | 1 Sep 2010 01:56
Favicon
Gravatar

Re: [Slight OT] TDPL in Russia

Andrei Alexandrescu wrote:
> Relevant reading:
> 
> http://www.paulgraham.com/taste.html
> 
> Art is indeed a relational value (has value only defined jointly by a 
> creator and a recipient) but that doesn't make it wholly relative.

Where I draw the line is when someone tries to impose their taste upon others.

My father was in the Air Force, and so often lived on military bases in base 
housing. On one, all the base housing furnishings were selected by the base 
commander's wife. Whether she had good taste or not was irrelevant, all the 
officers' wives *loathed* her picking out their furnishings and imposing it on them.
Permalink | Reply | 0 comments |
headers
Nick Sabalausky | 1 Sep 2010 02:16

Re: Bug 3999 and 4261

"Daniel Gibson" <metalcaedes <at> gmail.com> wrote in message 
news:mailman.24.1283298345.858.digitalmars-d <at> puremagic.com...
> ---
> int x;
> stream.read(x); // btw: this often sucks - why not x = stream.readInt()?

Better yet: stream.read!int()

> if(x == MyEnum.DIE)
> return 0;
> else if(x == MyEnum.CALLFOO)
> foo(x);
> ---
> or something like that (switch() might be better, but whatever).
>
> Also treating named and unnamed enums differently seems inconsistent to 
> me.
>

D's enums are *already* two completely different things. Some enums create a 
new type with a pre-determined set of possible values, and some *ahem* 
"enum"s *cough* just simply create a manifst constant and no new type.

I gotta say, I'm completely with bearophile on these enum issues. One of the 
things that drew me to D from C/C++ is the increased emphasis on *strong* 
typing, but D's enums (and the death of typedef, athough I do understand the 
reasons for that) make me feel like I'm right back in the middle of C's 
shitty so-called "type system".

Plus, even if you do want to treat a...*real* enum (such as MyEnum above) as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eduardo Cavazos | 1 Sep 2010 02:22
Picon

Overloading + on points

(Discussion originally on digitalmars-d-learn. Moving to digitalmars-d 
list.)

Eduardo Cavazos <wayo.cavazos at gmail.com> wrote:

 > Here's a short program which creates a type for points and overloads 
'+'
 > to do element wise addition as well as addition to floats, however it
 > produces an error:
 >
 > ----------------------------------------------------------------------
 > import std.stdio ;
 >
 > struct Pt
 > {
 >    float x , y ;
 >
 >    Pt opBinary ( string op ) ( Pt a ) if ( op == "+" )
 >      { return Pt ( x + a.x , y + a.y ) ; }
 >
 >    Pt opBinary ( string op ) ( float a ) if ( op == "+" )
 >      { return Pt ( x + a , y + a ) ; }
 > }
 >
 > void main () { Pt ( 1.0 , 2.0 ) + Pt ( 3.0 , 4.0 ) ; }
 > ----------------------------------------------------------------------
 >
 > The error:
 >
 > pt_overload_test_a.d(15): Error: template instance opBinary!("+")
(Continue reading)

Permalink | Reply | 1 comment |
headers
bearophile | 1 Sep 2010 02:23
Picon

Re: Bug 3999 and 4261

Daniel Gibson:
> I sometimes find it convenient to just treat those values as integers,

Yes, I am sure in some situations it can be handy. But it's a a bit of convenience that has a too much high price,
the semantics is less clean, and it's more bug prone. So no thanks. Keeping things tidy is more important.

Bye,
bearophile
Permalink | Reply | 1 comment |
headers
Daniel Gibson | 1 Sep 2010 02:38
Picon
Gravatar

Re: Bug 3999 and 4261

bearophile schrieb:
> Daniel Gibson:
>> I sometimes find it convenient to just treat those values as integers,
> 
> Yes, I am sure in some situations it can be handy. But it's a a bit of convenience that has a too much high
price, the semantics is less clean, and it's more bug prone. So no thanks. Keeping things tidy is more important.
> 
> Bye,
> bearophile

Then there still is the consistency-issue (anon. enums are treated 
differently then named enums).

Apart from that inconsistency: Yes, it wouldn't be unreasonable to just 
cast the int to MyEnum or the other way round for comparison.
(or, in my example: MyEnum x; stream.read(cast(int)x); ...)

Cheers,
- Daniel
Permalink | Reply | 0 comments |
headers
bearophile | 1 Sep 2010 02:59
Picon

Re: Bug 3999 and 4261

Daniel Gibson:
> Then there still is the consistency-issue (anon. enums are treated 
> differently then named enums).

Look at this:Se
enum int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...

Color is a sequence of symbols, Red, Green and Blue, named Color. When you write your program often all you
need to know is if color is Red or Green, and you don't care much how the compiler represents those symbols.
The n is a compile-time constant value. It's not a sequence of something.

Now, just for fun, replace the first enum with something as:

ctconst int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...

ctconst is a fictional keyword that denotes compile-time constants. Now you are probably able to see that
there is no correlation between the n and Color.

In D they are using the same keyword by accident, probably because Walter thinks that saving a keyword is
more important than keeping the semantics tidy.
So today you are probably struck with using "enum" to define compile-time constants.

The C++0x design group has not introduced the "enum class" for fun, their strong typing nature is useful to
make the code less bug-prone. See:
(Continue reading)

Permalink | Reply | 18 comments |

Gmane