[phobos] Time to get ready for the next release

[Robert Jacques]

On Mon, 25 Apr 2011 09:47:32 -0400, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:
> ----- Original Message -----
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos  
>> library for D <phobos at puremagic.com>
>> Cc:
>> Sent: Saturday, April 23, 2011 1:42 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>> On Fri, 22 Apr 2011 15:26:51 -0400, Steve Schveighoffer
>> <schveiguy at yahoo.com> wrote:
>> [snip]
>>>  Another analogy I like to draw upon is casing.  What if D's casing was
>> insensitive?  That is, ReadValue is the same thing as readValue and  
>> readvalue .There are probably many people who would love to always use  
>> their learned
>> conventions for calling your code (e.g. I always make methods upper  
>> case), but
>> then someone comes along and types in reAdvalue (my super-uncreative  
>> brain
>> can't come up with a clever example to show something worse, but you  
>> get the
>> idea).  The name is the same, but the casing makes all the difference to
>> interpreting what it means!  Like it or not, the same thing applies to  
>> things
>> like:
>>>
>>>  writeln = "hello";
>>>
>>>  Even though we know this is not the right way to call it, the compiler
>> doesn't give an error to enforce the semantics.
>>
>> The user is aways right. As a library designer, the user is your  
>> customer. And
>> if they discover a new (and meaningful to them) way to use your code,  
>> take it as
>> a chance to iterate in a new feature (or improve the design if it's a  
>> bug).
>
> It's impossible to improve the design when the compiler doesn't let you  
> enforce your design!
>
> And no, the user is not always right.  That's why we have the compiler  
> to tell them so ;)

Having D enforce your design, can not _ever_ improve a design. Every  
single time DMD rapts the user's knuckles enforcing your design, it is an  
instance where your design failed. It is a safety net. Nothing more.

Have a safety net is important, but the more it extends out beyond the  
concrete of invalid and meaningless code, the more it encourages mediocre  
design. And any fall into the safety net still hurts.