fixup for #3822

[MartinNowak]

• keep ptr and len as deprecated (unsafe) properties

[jmdavis]

Auto-merge toggled on

[ghost]

👏 You've just auto-assigned you the deprecation cycle of a stupid detail 👏

[jmdavis]

👏 You've just auto-assigned you the deprecation cycle of a stupid detail 👏

??? I'm already the one managing the deprecation cycles of stuff. Granted, it's kind of dumb to be deprecating an undocumented member, because someone used it in spite of it being undocumented, but having it deprecated for a bit doesn't hurt. We're minimizing code breakage here with minimal cost. It's a bit annoying, but I really don't see a problem with it.

[MartinNowak]

We're minimizing code breakage here with minimal cost. It's a bit annoying, but I really don't see a problem with it.

And that stupid detail broke gfm one of the most used dub packages.
Of course they would have worked around the issue in a later gfm version, but this forces anyone using 2.070.0 to update their gfm dependencies.
Creating such version skews harms even our tiny ecosystem.

[schveiguy]

This would be like gcc changing their FILE * implementation, and us complaining because we use the undocumented struct layout.

Anyone who uses undocumented implementation details, or depend on old libraries that use them is bound to have failures. I can't see how we can possibly be responsible for all invalid uses of phobos types in 3rd party libraries.

BTW, it's not gfm that was broken, it was regexp from the undead repository. AFAIK, that was fixed. gfm just needs to update their dependencies.

[jmdavis]

Anyone who uses undocumented implementation details, or depend on old libraries that use them is bound to have failures. I can't see how we can possibly be responsible for all invalid uses of phobos types in 3rd party libraries.

While, I agree, since it came up in the beta, I don't mind having it deprecated for a release or two to minimize the breakage (much as the person who did it wasn't careful enough). I don't intend to keep it around as deprecated for long though. A situation such as this definitely doesn't merit the full deprecation cycle. It's really just an attempt to be nice and minimize PR damage - even if it's caused by someone doing something that they shouldn't have been doing. If it actually cost us much to deprecate it, then I'd be a lot more inclined to make a stink over it, but all it really means is that it's one more item I have to watch for when moving the deprecations along, and it won't be there for long.

I will say though that this sort of situation does make me a bit more annoyed with the undead repo. The whole point of it was to put it off somewhere where someone could easily grab that code if they hadn't bothered to update their program in ages and needed it while still not having to maintain it in Phobos. But this looks an awful lot like we're having to maintain it anyway...

I would hope that any projects in code.dlang.org would move away from undead though rather than continuing to use it. The fact that we have undead arguably just encourages folks not to update their code. :|