Generality creep

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Mar 28 18:30:24 UTC 2019


On 3/28/19 2:12 PM, ag0aep6g wrote:
> On 28.03.19 18:04, Andrei Alexandrescu wrote:
>> On 3/28/19 9:16 AM, ag0aep6g wrote:
>>> On 28.03.19 14:05, Andrei Alexandrescu wrote:
>>>> Then some ranges are not meant to be assignable.
>>>
>>> Should Phobos be compatible with those ranges?
> [...]
>> It seems to me going with these is the right thing:
>>
>> * Input ranges are copyable and assignable, and have pointer semantics 
>> (all copies refer to the same underlying position, and advancing one 
>> advances all others).
>>
>> * Forward ranges are copyable and assignable, but distinct copies 
>> refer to distinct positions in the range such that advancing one does 
>> not advance the others.
>>
>> * We don't support other semantics.
> 
> Are you going to actually change the range definitions in that way? Are 
> you saying that I should wait until then with fixing range issues in 
> Phobos?
> 
> I'd expect those new definitions to be years away from becoming reality. 
> It doesn't seem wise to leave bugs open today just because you have 
> vague plans for fundamental changes in the distant future.

We've been worrying too much about changing things.

On any given issue, even those that widely agreed to be clowny, two 
factions emerge. One advocates change and the other advocates against 
code breakage. Interestingly the factions are different depending on the 
issue, i.e. a given person may be in favor of change in one matter and 
in favor of backwards compatibility in another. At any rate, the result 
is years-long stalemate and trench warfare on the slightest problems.

We should do what C, C++, Java, C# and many other languages do - leave 
past mistakes in maintenance mode and move on with new stuff. It's like 
blockchain - once done, it can't be undone. You do a new one. C has 
about three ways of converting numbers to strings and back. C++ added a 
couple, poorly designed. Then they added a better one. And don't get me 
started about I/O (two ways of doing it in C, and another one in C++ 
that nobody in their right mind would use). Same with Java pre- and 
post-generics interfaces for comparing objects. It's just that if 
something is bad they define a better one and move on.

We have a language with virtually no global scope - a versioning 
engineer's dream. Yet we are coy to tap into that power. Instead, we 
wring hands over the breakages that would happen if we change std.json. 
The time is ripe for std.v2, which would do the right things and support 
simple migration.




More information about the Digitalmars-d mailing list