Help!

[Sönke Ludwig]

Am 27.11.2012 18:47, schrieb Eldar Insafutdinov:
> On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
>> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>>> I agree, and if I remember previous discussions on the subject
>>> correctly, it seems like only Walter is in favor of upholding the
>>> current restrictions of "alias" parameters to symbols. I simply do not
>>> see a point in pushing compiler implementation details on the user like
>>> that – for the programmer, a type is a type is a type…
>>>
>>> Walter, do you have an example of a situation where the alias parameter
>>> restriction would be beneficial?  (for the D code involved, I don't mean
>>> the few lines of code avoided in the compiler)
>>
>> In any case, it will break a great deal of existing code to change  that behavior.
> 
> The discussed issue is one of those inconsistencies that make people struggle when using D. D's main
> selling point is rich meta programming. Others are rapidly catching up in the field of expressive
> native languages. If we set these early design decisions in stone, it means we will not be able to
> compete with them. And besides, are there many big proprietary D2 codebases that you afraid? I doubt
> there are. And Manu actually represents people who are willing to work on one, but are held off by
> these issues. Open source projects however will be easily fixable, and people using D will actually
> welcome these positive changes.

We do have a largish code base that is also gradually used commercially (200k+ lines of library
code, when including vibe.d plus any applications that are built on top of it). My former employee
now has a smaller code base along the lines of 80k+ LOC). So I guess such code bases are in fact a
reality.

... and still I very much prefer to have "good" breakage that cleans up the language. It's just
things that break code for nothing (most of the time bugs) that are really annoying.

And I fully agree, we should better collect warts of the language and fix them as early as possible.
This may set up a few people now, but will make all the future users of the language + a lot of the
current users much more happy.

Realistically, the current approach with one branch that is not supposed to get breaking changes,
but gets them anyway as soon as it _has to_, just extends the period of time in which things get
broken and also in which the language still has those issues.