Expand DEPRECATED functionality. about problem-solving

[0rir]

@2colours, this is about making existing behavior into defined behavior in the Raku spec.

Just throwing it into roast is good, but the existing code has some expectation of a specific style of version numbers.

[2colours]

Hi @0rir,

let me ask if I have this straight: is this about deprecation within the Raku language specification or any deprecation that can happen in code?

[codesections]

I would also support stabilizing a more powerful version of DEPRECIATED. For comparison, this is pretty similar to how Rust handles depreciation and it ends up being pretty useful in Rust user code.

[0rir]

Though I did propose a mess of features, I think there is one most necessary:
Decoupling the Raku version style to allow any kind of version string.

Then multis should allow a smooth expansion of functionality.

And my 'contact' and 'author' thoughts were ill-thought--passing a generic and a more specific message would be more flexible.

[vrurg]

Decoupling the Raku version style to allow any kind of version string.

Sorry, would you elaborate on this? I don't quite get what is it about and how you see it.

[0rir]

@vrurg, thanks.

My '-Since', '-Gone' in the above code require the hyphens to avoid an initial letter 'v' being added because the they become Version objects. I did not explore this aspect--it just seemed clear that, for general use, plain strings are appropriate.