The recent discussion regarding the switch statement raised a more fundamental issue.

Which of the following two goals should take precedence in D language design
issues:
1. compatibility with C or C++
2. striving for the best possible design

Where C/C++ (I know these are really two different languages) are considered to already embody best practices, this is not an issue.  However, I suspect most people with an interest in D will consider that this is often not the case.

Please note that I'm not trying to reopen discussion of the switch statement, but simply trying to establish which principle is normally going to govern D design.

Tony

> The recent discussion regarding the switch statement raised a more
fundamental
> issue.
>
> Which of the following two goals should take precedence in D language
design
> issues:
> 1. compatibility with C or C++
> 2. striving for the best possible design
>
> Where C/C++ (I know these are really two different languages) are
considered to
> already embody best practices, this is not an issue.  However, I suspect
most
> people with an interest in D will consider that this is often not the
case.
>
> Please note that I'm not trying to reopen discussion of the switch
statement,
> but simply trying to establish which principle is normally going to govern
D
> design.
>
> Tony

It can't be an all or nothing thing, surely? C and, especially, C++ are sometimes "wrong" in ways that end up being very powerful. For example, the behaviour of the language in selecting matching function overloads has led to all kinds of powerful techniques in template meta-programming. So sometimes it may not be best to ape what these languages have, since some of their power is accident, and which we can, one would hope, engineer more understandably and more easily with the benefit of hindsight and our compiler-walter.

But, the switch statement is not a good example of such. There were some rather serious differences of philosphical opinion which, IMO, have nothing to do with the particulars of D or any other language. The few people who argued for the C/C++ switch semantics status-quo did so (correct me if I'm wrong) not because they considered that it represents a zenith of design, but rather than it was less dangerous to tamper with current widely known but broken semantics, than to introducing surprising new broken ways.

IMO, D should have nothing to do with compatibility with C++ whatsoever. (Advertainment: for anyone stupid enough to be planning to buy my book next summer, there're 6 chapters covering why C++ is *not* a good language of inter-link-unit communication, and then, perversely, how to do just that ;).) But D absolutely must maintain compatibility with C, which is the lingua franca of multi-lingual programming for just about any language-language or language-technology that you can name. Note that not having C++ compatibility does *not* mean that C++ cannot interroperate with D. In the next release there'll be the std.recls module, which is implemented entirely in C++, using lots of modern jiggery pokery. It's just that it expresses a C API (as all C++ components should!). (Walter and I are hoping that this mapping from the C++ recls to D will serve as a good, or adequate at least, example for anyone else trying to do the same. It's undoubtedly the case that many D components will start life as D mappings; and probably many will always be so, which is perfectly appropriate.)

But just because D _can_ talk C, does not mean that that should be the limit of its ambition. I predict that, by the time Walter presents at next year's expo, D will have a whole new template architecture, which will facilitate generic programming from the ground up, not as the warty and dialectically-partial afterthought that is the case with C++. (Self-aggrandising aside: I am occasionally asked by Boost fans why STLSoft is so incomprehensible, and yet when I look at Boost code my brain freezes; that just seems to be the way of C++ template programming: it's the most clique-y thing in IT. The more frequent question is why it does not use Boost, or why it is not part of Boost. I'll leave those questions as an exercise for the reader, and maintain a politic silence ...)

Anyway, I've crapped (/carped?) on far too much, as is my wont. I think we
should always aim for the highest highs in D, which are (in semi-random
order):

- efficiency
- robustness
- maintainability
- flexibility

Anytime the language can promote any/all of the last three without sacrificing the first one, I think we should strongly consider the merits.

Cheers

-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

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

You left out

3) Safer than C/C++

I of course want 2 to be the primary objective, with 3 coming in second, then 1.

In article <brrnjq$2a3q$1@digitaldaemon.com>, Tony West says...
>
>The recent discussion regarding the switch statement raised a more fundamental issue.
>
>Which of the following two goals should take precedence in D language design
>issues:
>1. compatibility with C or C++
>2. striving for the best possible design
>
>Where C/C++ (I know these are really two different languages) are considered to already embody best practices, this is not an issue.  However, I suspect most people with an interest in D will consider that this is often not the case.
>
>Please note that I'm not trying to reopen discussion of the switch statement, but simply trying to establish which principle is normally going to govern D design.
>
>Tony
>
>

I definitely am in camp #2.  I would only want #1 if it's a tossup and there isn't any clearly better way to do it, then the way C chose is preferred since people are familiar with it.  But if C is broken in any way, I would prefer that D attempt to fix it.

Sean

"Tony West" <Tony_member@pathlink.com> wrote in message news:brrnjq$2a3q$1@digitaldaemon.com...
> The recent discussion regarding the switch statement raised a more
fundamental
> issue.
>
> Which of the following two goals should take precedence in D language
design
> issues:
> 1. compatibility with C or C++
> 2. striving for the best possible design
>
> Where C/C++ (I know these are really two different languages) are
considered to
> already embody best practices, this is not an issue.  However, I suspect
most
> people with an interest in D will consider that this is often not the
case.
>
> Please note that I'm not trying to reopen discussion of the switch
statement,
> but simply trying to establish which principle is normally going to govern
D
> design.
>
> Tony

Tony West wrote:

>The recent discussion regarding the switch statement raised a more fundamental
>issue.
>
>Which of the following two goals should take precedence in D language design
>issues:
>1. compatibility with C or C++
>2. striving for the best possible design
>
>Where C/C++ (I know these are really two different languages) are considered to
>already embody best practices, this is not an issue.  However, I suspect most
>people with an interest in D will consider that this is often not the case.
>
>Please note that I'm not trying to reopen discussion of the switch statement,
>but simply trying to establish which principle is normally going to govern D
>design.
>
>Tony
>  
>
If we support 1 then we end up with C++ again.  So 2 is the obvious choice.

-Anderson