Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The status of PREVIEW modifier. #34

Closed
vrurg opened this issue May 31, 2019 · 3 comments
Closed

The status of PREVIEW modifier. #34

vrurg opened this issue May 31, 2019 · 3 comments
Assignees
Labels
language Changes to the Raku Programming Language

Comments

@vrurg
Copy link
Contributor

vrurg commented May 31, 2019

I didn't plan this for today but the discussion we've got on IRC is probably requiring continuation.

It is all about the question how to we handle PREVIEW modifier. I proposed to deprecate 6.d.PREVIEW soon after the next rakudo release. Deprecation means that any use of the version in code will produce a compile-time warning. No other side effects. In a couple of release cycles deprecated modifier can be dropped and this is where its use would result in an error.

I also drafted my vision in Building Rakudo paper.

What is my point behind having PREVIEW dropped over time. Some proposed features for one reason or another may not make it into the release. Their implementations are not to be kept in the core forever (unless their acceptance has been postponed for the next release). Deprecation of PREVIEW is a signal for those still using it to reconsider their code and refactor it to conform to supported releases. Wether or not PREVIEW is removed after that is not that important anymore. But as long as no experimental code bound to it is left in the core – what is the point of keeping it?

This is just one point of view. A short talk on IRC has revealed a few more and I hope will see them here.

@AlexDaniel
Copy link
Member

AlexDaniel commented May 31, 2019

Some proposed features for one reason or another may not make it into the release. Their implementations are not to be kept in the core forever (unless their acceptance has been postponed for the next release). Deprecation of PREVIEW is a signal for those still using it to reconsider their code and refactor it to conform to supported releases.

I think there is a misunderstanding. At least in case of v6.d.PREVIEW, it does not mean that features that were dropped for 6.d release are somehow still supported in v6.d.PREVIEW. In other words, v6.d.PREVIEW is v6.d. And yes, before v6.d was released, v6.d.PREVIEW was allowed to change in any way so it was not recommended (so users who put that into their code did that at their own risk). use v6.d.PREVIEW is simply a way of saying “I want v6.d semantics even though v6.d is not released yet”.

Am I making sense? And if so, is there any other problem with keeping v6.d.PREVIEW available?

@AlexDaniel AlexDaniel added the language Changes to the Raku Programming Language label May 31, 2019
@vrurg
Copy link
Contributor Author

vrurg commented May 31, 2019

I see your point and I'm ok with keeping it. The purpose is to hear other people if they want to speak out their minds.

I would only ask if we're going to stick to the approach of preserving PREVIEW for 6.e+ too?

@vrurg
Copy link
Contributor Author

vrurg commented Jun 2, 2019

There is a good point on this in rakudo/rakudo#2464. Closing.

@vrurg vrurg closed this as completed Jun 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language Changes to the Raku Programming Language
Projects
None yet
Development

No branches or pull requests

3 participants