http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 31 December 2014 at 10:09, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>"
> wrote:
>>
>> In general, I get the impression from both DIP25 and DIP69 that both are
>> motivated by minimizing the change to the existing language, instead of
>> looking
>> for the most powerful solution (that may have other use-cases besides the
>> ones
>> under consideration). I.e., instead of asking which concepts are behind
>> the
>> problem in question, how these concepts could be expressed in an ideal
>> world,
>> and then making compromises to fit them into D, it seems like we're
>> starting
>> with some premises (as few changes as possible, no type modifiers), and
>> then
>> look for a solution that needs to sacrifice the smallest number of use
>> cases to
>> stay within the constraints. This is particularly bad if our premises are
>> going
>> against the nature of the problem we want to solve, because then we are
>> guaranteed to get a bad solution.
>
>
> On the other hand, power just because we can add it is not always a good
> thing. C macros are very powerful, but experience has shown it is the wrong
> kind of power. Also, programmers do not really want a complex annotation
> system. They want to just write code in the most obvious manner and have it
> work correctly. Having a powerful (but complex) system is not very
> attractive.

His point is similar to my other point elsewhere though. I don't think
he's talking about 'power' in the sense you describe, what he's really
talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to have
been introduced to try and 'contain the concept into a smaller space',
if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do; talk
about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet more
edges to address specific cases, rather than removing the edges that
are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off rough edges.