http://wiki.dlang.org/DIP25

[via Digitalmars-d]

On Wednesday, 31 December 2014 at 00:09:15 UTC, Walter Bright 
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.

So... how does this apply to our problem concretely? Do you 
believe a full blown ownership/lifetime system is "the wrong kind 
of power"? Remember, we're talking about an ideal world at first. 
If after thorough discussion it turns out that it can't be 
integrated into D, at least we know that it's probably not 
possible. But I haven't seen any indications that this is the 
case; in fact, it's not even been discussed.

> 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.

But a powerful system doesn't need to be complicated. In fact, a 
system with a handful of general and orthogonal features is 
likely easier to understand and handle in practice than one with 
lots of (even trivial) edge cases and exceptions.