Generality creep

[Andrei Alexandrescu]

On 4/4/19 12:24 AM, Andrei Alexandrescu wrote:
> On 4/3/19 11:09 PM, Nicholas Wilson wrote:
>> On Thursday, 4 April 2019 at 02:05:15 UTC, Andrei Alexandrescu wrote:
>>> On 3/31/19 6:25 PM, Manu wrote:
>>>> Sure. But in the meantime, fix the objective bug with the current
>>>> semantics where you can read/write un-protected data freely. Right
>>>> now. Please for the love of god
>>>
>>> This does not work as a two stages process, though the "stop the 
>>> bleeding first then come with the new solution" metaphor seems 
>>> attractive. The main issues being when we break code that people got 
>>> to work, we need to offer the alternative as well. Another being that 
>>> the exact kind of things we disable/enable may be dependent on the 
>>> ultimate solution.
>>
>> Well whatever happens I'll be gobsmacked if its not behind an opt in 
>> switch.
>> With that in mind, if Manu gets use out of the stopgap of disabling 
>> read/write access, then I think we should implement that ASAP and then 
>> listen to whatever he complains about next ;)
>>
>>> This would be a large effort requiring a strong team. Walter, 
>>> yourself, and I would be helpful participants but I think between the 
>>> three of us we don't have the theoretical chops to pull this off. At 
>>> least I know I don't. We need the likes of Timon Gehr, Johan Engelen, 
>>> and David Nadlinger (whom I cc'd just in case).
>>
>> I don't think we are going to be able to do this without iterating on 
>> the design and closing holes and nuisances that we discover. I'm not 
>> saying that it is a bad idea to design up front as much as we can, but 
>> we shouldn't wast time getting hung up on design when implementation 
>> can give gains to users and guidance to the design.
> 
> I don't think this works for programming language design. In fact I'm 
> positive it doesn't. It's the way we've done things so far.

Well I'm exaggerating. I mean to say every time we did it that way, the 
result hasn't been good.