Sean Kelly wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Derek Parnell wrote:
>>>
>>>> The current decision to reuse 'enum' for manifest constants is yet another
>>>> example of a designer believing that their intuition is better than their
>>>> customers', regardless of any evidence to the contrary. Please reconsider
>>>> that there might be a remote possibility that this decision is actually
>>>> wrong in this case; 'enum' is not the best choice for developers when it
>>>> comes to declaring manifest constants.
>>>
>>> There are a number of people who strongly feel it is the correct decision who are not vocal about it.
>>
>> I don't suppose the use of 'enum' in this context has had any impact on named enumerations?  ie. We still cannot have a named enum which contains strings, correct?  Also, are traditional unnamed enums still legal?
>>
>> enum
>> {
>>     a, b, c
>> }
>>
>> enum : long
>> {
>>     d, e, f
>> }
> 
> err... assume there are values assigned to the members above.

Seems it does still work that way.  It's not a big thing, but is perhaps worth mentioning that the new enum feature does change the behavior of existing code:

    enum
    {
        a = byte.max
    }

    void main( char[][] args )
    {
        printf( "%.*s: %d\n", typeid(typeof(a)).toString, a );
    }

Under D 1.0 this prints:

    int: 127

And under D 2.0 this prints:

    byte: 127

I can see this causing occasional rare problems for code transitioning to 2.0, but probably nothing serious.  Fortunately, this is disallowed in 1.0:

    enum { a = long.max }


Sean

Lars Ivar Igesund wrote:

> If one were to have a "panel" of experienced users, one should strive to have one with equally much experience in the various big languages (too bad that it is hard finding anyone with 10+ years in Java and 5+ in C#). As it is now, the overweight of C++ seems to be too big (from the outside), which sounds doubly bad considering D is touted as a language fixing C++ mistakes. Most C++-users I know refuse to even acknowledge that C++ is bad.

C++ user here.

C++ and Java are both just hopelessly outdated. However, when C++ was new it was the best language of its type around. And after many years of use it has become extremely stable and reliable. Because it is so popular, it is also impossible to change the meaning of anything as often used as enum.

I will agree that C++ is not perfect. But it is not bad. If you claim it is, I'd like to hear some arguments.

At first I really liked the D specs. The explicit contracts / invariants / unittests, the useful template possibilities, the variadic functions, to name a few. But right now D seems far too unstable and convoluted for me. It's already past version 1, well into 2 and already planning for 3. Not so much fixing and stabilizing (or, you know, standardizing) the existing language as adding more and more features. I'm glad I have something as reliable as C++ to work with.

Now I will admit that I haven't used D for some time and am mostly going by what I read in this newsgroup. And I'll be happy to hear counter-arguments.

-- 
Michiel

Michiel Helvensteijn wrote:
> Lars Ivar Igesund wrote:
> 
>> If one were to have a "panel" of experienced users, one should strive to
>> have one with equally much experience in the various big languages (too
>> bad that it is hard finding anyone with 10+ years in Java and 5+ in C#).
>> As it is now, the overweight of C++ seems to be too big (from the
>> outside), which sounds doubly bad considering D is touted as a language
>> fixing C++ mistakes. Most C++-users I know refuse to even acknowledge that
>> C++ is bad.
> 
> C++ user here.
> 
> C++ and Java are both just hopelessly outdated. However, when C++ was new it
> was the best language of its type around. And after many years of use it
> has become extremely stable and reliable. Because it is so popular, it is
> also impossible to change the meaning of anything as often used as enum.
> 
> I will agree that C++ is not perfect. But it is not bad. If you claim it is,
> I'd like to hear some arguments.
> 
> At first I really liked the D specs. The explicit contracts / invariants /
> unittests, the useful template possibilities, the variadic functions, to
> name a few. But right now D seems far too unstable and convoluted for me.
> It's already past version 1, well into 2 and already planning for 3. Not so
> much fixing and stabilizing (or, you know, standardizing) the existing
> language as adding more and more features. I'm glad I have something as
> reliable as C++ to work with.
> 
> Now I will admit that I haven't used D for some time and am mostly going by
> what I read in this newsgroup. And I'll be happy to hear counter-arguments.
> 

There is a bit of confusion around D versions, and it seems to be a result of the versioning system in use.

* D 1.x represents the stable version of D; bugs continue to be fixed; no new features are added (nor are features usually removed).

* D 2.x is really just the experimental/developmental version of D (think 1.9999); it's not intended to be stable or even used for general development; new features are added, changed, and removed with almost every release.  I think it was somewhat of a mistake calling it D 2.0 because it confuses people into thinking it's a final release.

-JJR

Michiel Helvensteijn wrote:

> Lars Ivar Igesund wrote:
> 
>> If one were to have a "panel" of experienced users, one should strive to have one with equally much experience in the various big languages (too bad that it is hard finding anyone with 10+ years in Java and 5+ in C#). As it is now, the overweight of C++ seems to be too big (from the outside), which sounds doubly bad considering D is touted as a language fixing C++ mistakes. Most C++-users I know refuse to even acknowledge that C++ is bad.
> 
> C++ user here.

Previous user here (may still return for the right contract, but it is
unlikely).

> 
> C++ and Java are both just hopelessly outdated. However, when C++ was new it was the best language of its type around. And after many years of use it has become extremely stable and reliable.

This weren't the truth only a few years ago, when any cross platform use made exceptions and anything but trivial templates banned from the projects I worked on. If the specification is too difficult to implement in homogenous way, then I won't call it reliable (although the spec itself is stable).

> Because it is so popular, it
> is also impossible to change the meaning of anything as often used as
> enum.

Sure. I accept that there won't be more changes to D 1.0

> 
> I will agree that C++ is not perfect. But it is not bad. If you claim it is, I'd like to hear some arguments.

And sure C++ is not the worst thing ever. Overall, I consider it bad. I'm bad at good argumentation over this, but after I've been using D and Java (and a very short bout of C#) for some years after I did any serious C++, I am convinced, deep into my heart, that most details (often just syntactical stuff! The features are mostly good, and it certainly creates fast executables) can be improved upon, and often in a major way. D shows this. C++ is a very big language, bigger yet than D (at least as far as the spec goes) and almost everything is possible through some (probably) non-intential way that has become convention and rooted into specification and/or use-base libraries. The thing here is that those conventions tend to crop up in the D discussions as good reasons to do those things the same way in D, and _that_ is what frustrates me. I do _not_ think overloading a keyword with a new meaning in anyway reduce language bloat (the feature is still there, even if it don't have a keyword of its own).

> 
> At first I really liked the D specs. The explicit contracts / invariants / unittests, the useful template possibilities, the variadic functions, to name a few. But right now D seems far too unstable and convoluted for me. It's already past version 1, well into 2 and already planning for 3. Not so much fixing and stabilizing (or, you know, standardizing) the existing language as adding more and more features. I'm glad I have something as reliable as C++ to work with.

As has been pointed out, the versioning of D is a bigger problem than stability itself as it is confusing. 1.0xx is stable, 2.0xx is not (and I have no idea how the version is meant to look when it becomes stable).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:

> C++ is a very big language, bigger yet than D (at least as far as
> the spec goes) and almost everything is possible through some (probably)
> non-intential way that has become convention and rooted into specification
> and/or use-base libraries. The thing here is that those conventions tend
> to crop up in the D discussions as good reasons to do those things the
> same way in D, and _that_ is what frustrates me. I do _not_ think
> overloading a keyword with a new meaning in anyway reduce language bloat
> (the feature is still there, even if it don't have a keyword of its own).

I agree. Overloading an existing keyword is not the answer. It can only cause confusion. Even though it does have the merit of not breaking existing code.

No, C++ convention is not a reason to do the same in a new language. And I even think D is still too much like C++. To name a trivial example, the assignment operator should not be =. It should be non-symmetrical, like <- or :=.

You know, some people might say that it should even be ->. As in, expression left, variable right. But this convention is so rooted into every programmers mind, even I wouldn't change it anymore.

>> At first I really liked the D specs. The explicit contracts / invariants / unittests, the useful template possibilities, the variadic functions, to name a few. But right now D seems far too unstable and convoluted for me. It's already past version 1, well into 2 and already planning for 3. Not so much fixing and stabilizing (or, you know, standardizing) the existing language as adding more and more features. I'm glad I have something as reliable as C++ to work with.
> 
> As has been pointed out, the versioning of D is a bigger problem than stability itself as it is confusing. 1.0xx is stable, 2.0xx is not (and I have no idea how the version is meant to look when it becomes stable).

Hm.. Yes. I might have a look at 1.0xx again. However, what's the point if I have to switch to 2.0xx (or whatever the stable equivalent is) in a year and have to rewrite all my 1.0xx code? The good thing about the development of C++ is that:

1. It is standardized.
2. For every new version, changes are painstakingly examined to make sure
they break as little existing code as possible.

-- 
Michiel

Michiel Helvensteijn wrote:

>>> At first I really liked the D specs. The explicit contracts / invariants / unittests, the useful template possibilities, the variadic functions, to name a few. But right now D seems far too unstable and convoluted for me. It's already past version 1, well into 2 and already planning for 3. Not so much fixing and stabilizing (or, you know, standardizing) the existing language as adding more and more features. I'm glad I have something as reliable as C++ to work with.
>> 
>> As has been pointed out, the versioning of D is a bigger problem than stability itself as it is confusing. 1.0xx is stable, 2.0xx is not (and I have no idea how the version is meant to look when it becomes stable).
> 
> Hm.. Yes. I might have a look at 1.0xx again. However, what's the point if I have to switch to 2.0xx (or whatever the stable equivalent is) in a year and have to rewrite all my 1.0xx code? The good thing about the development of C++ is that:
> 
> 1. It is standardized.
> 2. For every new version, changes are painstakingly examined to make sure
> they break as little existing code as possible.
> 

That is good for broad acceptance, but it is also among the reasons for why C++ has gotten a bad reputation in many places. It just picks up more cruft :)

As for D, the D 1.0 marker was very artificial, and so it is far from perfect, but still very good (and after being around D for a while, very relaxing to not have to change on every compiler release). That 2.0 may be marked as stable within a year may become a problem though, since it will have improved immensely upon 1.0 and for many projects an upgrade will be hard to avoid (I know we in Tango land have some expectations).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Sean Kelly wrote:
> I don't suppose the use of 'enum' in this context has had any impact on named enumerations?  ie. We still cannot have a named enum which contains strings, correct?

You can do named enums with strings now.

> Also, are traditional unnamed enums still legal?

Yes.

> enum
> {
>     a, b, c
> }
> 
> enum : long
> {
>     d, e, f
> }

Janice Caron wrote:
> On 1/1/08, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> What was the fundamental problem with creating some syntax that would
>> let you peel the reference part off a class reference?

Thanks for taking the time to write out the explanation below.

> It needs to be defined for all types, not just classes. If C is a
> class, and we define
> 
>     const(C)&
> 
> to mean mutable-reference-to-const-data, then you have only
> /partially/ defined &. You need to define it for all types. You need
> to define what
> 
>     const(T)&
> 
> means, for all possible types T. You need to define it for each of the cases:
> 
>     T is a primitive type
>     T is a pointer to U
>     T is an array of U
>     T is an associative array of U[V]
>     T is a struct
>     T is a union
>     T is a function
>     T is a delegate
>     T is a typedef
>     T is a named enum
> 
> Until it is fully defined, it is not possible to discuss its
> consequences. The fundamental problem is, things start to fall over
> when you start trying to define it for struct and union.

Seems easy enough.  Just make it mean no-op for the things where it doesn't make sense, namely things that aren't pointers.

struct Struct { int* p; int v; }
class Class { int* p; int v; }

const(int*)&     equiv to  const(int)*
const(int)&      equiv to  const(int)
const(Struct*)&  equiv to  const(Struct)*
const(Struct)&   equiv to  const(Struct)
const(Class)&    equiv to  const(Class)&

So this doesn't seem to be the point yet where "things start to fall over" that you speak of.

--bb

Lars Ivar Igesund wrote:
> It is hard to try to be involved (in any capacity) with D language evolution
> when there are silent (or rather non-public) opinions that weighs more than
> this newsgroup, and I think as people on the newsgroup figures this out, it
> will be a loss for D.

It is not that various opinions weigh more. It is more trying to pick the best possible course of action. Note that I do my best to argue the cases based on their merits, not based on votes. Consider that after the feedback in this group, the first two const regimes were scrapped. You guys made a convincing argument that it was confusing, overly complex, and basically sucked.

> In earlier situations that are similar to this one, it has always looked
> like the unvocal persons are C++-users, thus we end up in a very C++
> inspired language when that often is definately not what we want.

const in D is very unlike const in C++.

> Most C++-users I know refuse to even acknowledge that C++ is bad.

Interestingly, many C++ users I know will not publicly acknowledge the flaws in C++. Off the record, though, they say very different things. People do not want to damage their careers built up around C++. There are some pretty high level C++ experts who have been privately very helpful to me in explaining how to do things right.

Bill Baxter wrote:
> What was the fundamental problem with creating some syntax that would let you peel the reference part off a class reference?

const(C)&[] a;

is a sortable array of constant C's. But what is:

const(int)&[] a;

Is it sortable or not? If it is sortable, then & means "tail const". If it is not sortable, then how, in generic code, do we specify a sortable array of type T?

const(T)&[] a; // is it sortable or not?

Now, if & is to mean "tail const", what do we do with:

struct S
{ int i;
  int* p;
  void foo() { *p = 3; }
}

const(S)& s;

Does that mean we can modify the members of S, but not what those members may point to? How do we specify that member function foo is "tail const" ?

And what do we do with:

struct S { C c; }
const(S)&[] a;

Here, we've wrapped a class with a struct. Is it possible to make S behave like its underlying C? If not, we don't have general purpose UDTs. We have a heaping pile of special cases.