Clojure and Pull Request Controversy

Steven Schveighoffer schveiguy at gmail.com
Fri Nov 30 19:08:28 UTC 2018


On 11/30/18 1:41 PM, Dukc wrote:
> On Friday, 30 November 2018 at 18:16:37 UTC, Andre Pany wrote:
>> Just thinking loud: if the libraries are incompatible and you get an 
>> error while trying to use them together, that would be a good thing. 
>> There is no silent breakage. The third party library authors can be be 
>> contacted and asked to update their libraries.
> 
> In that way, yes, a good thing. But I completely disagree with it being 
> a good idea nonetheless. The problem isn't that the libraries need to be 
> updated, the problem is that they need to do so immediately.
> 
> For library upkeepers, such global versioning would be effectively as 
> bad as just removing autodecoding overnight without any deprectation 
> period. Or perhaps even worse, since they would probably have to leave 
> behind compatibility with autodecoding version, as there are always 
> libraries that won't migrate quickly enough.
> 
> Of course, we could say that the libraries, when they migrate, need to 
> keep backwards compatibility, so late migrators will keep working. But I 
> can hardly imagine that every library keeper will bother and remember to 
> test both versions.

There are going to be many cases I think where it just works, no matter 
what you care about auto-decoding.

For example searching for a string in a string doesn't matter whether 
the string uses auto-decoding or not.

For low-level code, you need to pick autodecoding or not autodecoding, 
and we need a deprecation period, Like Nick suggested. This means that 
for a period of time, a string won't be a range(!), you have to select 
byCodeUnit or byCodePoint (or similar). I think to make things easier, 
we can provide convenience aliases (like bcp or bcu), so it's not as 
painful. We will likely have workarounds all throughout phobos, that 
will then be removed once the deprecation period is over.

But painful, it will be. However, mostly for low-level code (i.e. code 
that uses string.front and string.popFront). May want low-level code 
conveniences too (frontCodeUnit, frontCodePoint?)

However, the end result is after the deprecation period, things can go 
back to being reasonable, and autodecoding-free.

We will see how bad it is, once it's tried. I'm hoping not very bad.

-Steve


More information about the Digitalmars-d mailing list