On Monday, 30 April 2012 at 18:09:32 UTC, Era Scarecrow wrote:
>
>  Then perhaps the comma operator can be pushed to the 'depreciated' list for a while; If it breaks anything big and important, you can still compile it. After a while we can see if it should be kept or removed. I think that's the best approach all things considered.
>
>  Personally, I have yet to really use it outside of a for/foreach statement. On the other hand if it breaks something, generally it will become quite clear where in few the few places and require you to fix and update it before moving on.

What we need is a "style guide", ala Scott Meyer, i.e try to find D idioms, how to write good code, what to avoid. Because even though it's harder to write bad code in D than in C++, it's always possible to write code with low performance, or be bitten by some traps.

Here is an example: http://forum.dlang.org/post/mailman.9.1335539605.24740.digitalmars-d-learn@puremagic.com

Timon Gehr:

> I think I use it about every 60 lines of code. Also, I don't think it should be removed for the sake of removing it. If it is removed, the syntax should be reused.

Commas do cause some bugs, so maybe they are worth restricting (further) even if their syntax doesn't get reused.

Bye,
bearophile

Andrej Mitrovic:

>> 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];
>
> But you can already use this syntax right now?

But there is a syntax problem:
http://d.puremagic.com/issues/show_bug.cgi?id=4703

Bye,
bearophile

On Monday, 30 April 2012 at 19:24:50 UTC, Walter Bright wrote:
>
> This certainly seems to have become the biggest thread ever!

What did you expect, really ? That people would say "nothing, the language is perfect" ? :D

When I saw your question, I immediately thought "damn, Walter is starting a troll thread for fun, it's gonna be a huge waste of time". :D

But then I changed my mind, because what I saw, - and that's what I expected actually -, is that almost everybody had a different list from other people. Which is in fact good, because that means that everybody uses his own subset of the language for his own use, and although there is a common ground, the union of all subsets seems to pretty much fill the "design space" of the language.

In the end, very few "features" seem to be universally disdained (the comma operator seems to come regularly, though, but even that one has supporters). Which means to me that in terms of overall design, the language is not in a bad shape at all.
So the design phase seems almost complete. The real effort now must be to finish the implementation, and build a full productive ecosystem. And I suppose we are still far from that goal.

On 4/30/2012 1:33 PM, Steven Schveighoffer wrote:
> I think we've already covered this -- opApply does things that ranges could
> never do.

deprecating opApply would require addressing this.

On Monday, 30 April 2012 at 19:08:54 UTC, Andrej Mitrovic wrote:
> On 4/30/12, SomeDude <lovelydear@mailmetrash.com> wrote:
>> I'd like to have a bit of an idea of how
>> fast the compilers really are.
>
> Personally my gripe with compilation times is that I get very used to
> having fast build times where I can go through an edit+compile+run
> cycle really fast, but after a while build times get slower
> (especially when templates get in the mix) and this really throws me
> off. Sometimes I wish I could just interpret D code at runtime just to
> save on compilation time, because I might just be testing the
> semantics of code and not necessarily its performance at a time.

Yeah, templates is what slows everything down. I'd be very wary of using Boost in C++, for instance, because heavy usage of templates in C++ can slow your development cycle to a crawl in a large project.

But in D, the risk of recompilation is limited by the module system, right ?

On Monday, 30 April 2012 at 21:11:20 UTC, SomeDude wrote:
> But in D, the risk of recompilation is limited by the module system, right ?

Also, in D, bugs in the CTFE slows everything down, in particular this one: http://d.puremagic.com/issues/show_bug.cgi?id=6498

On Monday, 30 April 2012 at 18:32:36 UTC, Nick Sabalausky wrote:
> "SomeDude" <lovelydear@mailmetrash.com> wrote in message
> news:ajdmseliewbindkkoxxj@forum.dlang.org...
>>
>> [...]There would be no longer any need for the "in" and "out" keywords.[...]
>
> void foo()
> in{ ... }
> out{ ... }
> body{ ... }

OKay, I meant in the function signatures

Walter:

> The first thing to emphasize is that NONE of this will happen for D2. The emphasis on D2 is fixing implementation and toolchain issues. Breaking existing code is off the table unless we are pretty much forced to in order to fix some other more important issue.

But you need to keep into account that D2 is still a not widely used language. So deprecating some things now will cause far less troubles than doing it in D3 some years from now. So I suggest to be a bit more flexible on this.


> We've had some success in deprecating mistaken features - the bit data type, and typedefs.

In the end I agree that deprecating typedef was the right thing. Not because it's useless, quite the contrary, but because it was not well designed, so it's better to remove it to have a chance later to get it more right. Adding if far simpler than removing. But keep in mind that Phobos Typedef is so broken that it's essentially not usable in practical situations (quite more broken even than emplace and rebindable, that have several problems). So we don't have a replacement yet.

Bye,
bearophile

Walter:

> The evolution of C++ is interesting.

I think the evolution and updating patterns of the language Scale are more interesting for us.

Bye,
bearophile