Re: The D Programming Language

Re: The D Programming Language

[David Rasmussen]

Mark Hahn wrote:
> the classic "it's OK because everyone does it" argument.
> 

That wasn't really my point. My point was that some level of 
off-topic-ness seems to be ok, as long as it relates to something 
on-topic. Walter wrote because he would like a D frontend in gcc. And 
before anyone went ahead and implemented it, I just wanted to make this 
addition, without which the language is worthless :)

/David

Re: The D Programming Language

[Robert Lipe]

David Rasmussen wrote:

> Robert Dewar wrote:
>
> >Surely this is the wrong list for general chit chat on language
> >design
>
> The "Count 1-bits in 64-bit number" wasn't exactly on-topic either.

That conversation didn't belong here either, and several people politely
asked that it go away.

RJL

Re: The D Programming Language

[David Rasmussen]

Robert Dewar wrote:
> Surely this is the wrong list for general chit chat on language design
> in general (and in particular chit chat about the design of D!)
> 
> 

You are right of course. Still, this list have a lot of not strictly 
on-topic but related discussions. The "Count 1-bits in 64-bit number" 
wasn't exactly on-topic either.

/David

Re: The D Programming Language

[David Rasmussen]

Tim Hollebeek wrote:
>>The difference from enums is that
>>
>>1. They don't implicitly cast to anything. I find that a source of bugs 
>>with enums.
>>
>>2. They can't eventually end up having some undefined value, internally 
>>represented as 42 or something. This can happen with enums.
> 
> 
> Worse, it is explicitly legal in C++.  For example, there is nothing
> wrong with: 'November | December' == 0x0c == nothing, which was an
> explicit decision to preserve the validity of code that uses enums to
> define bits.
> 
> This prevents compilers from optimizing or diagnosing invalid enum values.
> 
> -Tim
> 
> 

Exactly. That's what I'm talking about. These kind of types are missing 
from C, C++ and Java. They really should be in D.

What do you say, Walther?

Re: The D Programming Language

[Robert Dewar]

Surely this is the wrong list for general chit chat on language design
in general (and in particular chit chat about the design of D!)

Re: The D Programming Language

[Tim Hollebeek]

> The difference from enums is that
> 
> 1. They don't implicitly cast to anything. I find that a source of bugs 
> with enums.
> 
> 2. They can't eventually end up having some undefined value, internally 
> represented as 42 or something. This can happen with enums.

Worse, it is explicitly legal in C++.  For example, there is nothing
wrong with: 'November | December' == 0x0c == nothing, which was an
explicit decision to preserve the validity of code that uses enums to
define bits.

This prevents compilers from optimizing or diagnosing invalid enum values.

-Tim

Re: The D Programming Language

[David Rasmussen]

 > I have now released the source to the front end for the D compiler
 > as a dual
 > license (Artistic and GPL). Is anyone interested in hooking up the D
 > front end to the GCC optimizer/code generator to create a GPL'd D
 > compiler?
 >
 > -Walter
 > www.digitalmars.com/d/

D support in gcc would be very nice!

I have been monitoring the progress of D. I like the language very much. 
It hits several of my own reservations of C++ right on the spot. There 
is one important feature missing, IMO though.

Strong enumerable types with iteraton, like in Pascal:

  type
       MonthType = (January, February, March, April, May, June,
                    July, August, September, October, November,
                    December);

The difference from enums is that

1. They don't implicitly cast to anything. I find that a source of bugs 
with enums.

2. They can't eventually end up having some undefined value, internally 
represented as 42 or something. This can happen with enums.

3. You can loop over them like

for a := January to February do
	something;

You can of course loop over enums too, but that requires that you are 
able to go "one past the last", which I've found is a source of bugs. If 
an enum can ever become December + 1 (as it will to meet the stop 
criterion of a loop), which isn't meaningful. I find this to be a source 
of bugs as well.

Of course, looping over such types can be done with do and while loops, 
but we will have to find a way to use for loops with such types as well. 
I know that for loops in C wasn't designed for this, but I really think 
it is ugly that C for loops require that we go "one past the last". It 
is a source of bugs.

/David

The D Programming Language

[Walter]

I have now released the source to the front end for the D compiler as a dual
license (Artistic and GPL). Is anyone interested in hooking up the D front
end to the GCC optimizer/code generator to create a GPL'd D compiler?

-Walter
www.digitalmars.com/d/