Skip to content

Repository for maintaining proposal for changes to the Haxe programming language

Notifications You must be signed in to change notification settings

DawDavis/haxe-evolution

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 

Repository files navigation

Haxe change proposals

This project is for maintaining formal change proposals for Haxe language.

List of accepted proposals

# Name Author Status
0001 Any type Dan Korostelev implemented in 3.3.0
0002 Arrow functions Alexander Kuzmenko implemented in 4.0.0
0003 New function type syntax Dan Korostelev implemented in 4.0.0
0004 Intersection types Simn implemented in 4.0.0
0005 key => value iteration syntax Dan Korostelev implemented in 4.0.0
0006 Inline markup Juraj Kirchheim implemented in 4.0.0
0007 Module-level functions and variables Dan Korostelev implemented in Haxe 4.2.0
0008 Expression macro method forwarding Dan Korostelev to be implemented
0009 Inlining functions at call location YellowAfterlife implemented in 4.0.0
0010 New asys APIs Aurel Bílý to be implemented
0011 Local bariable metadata syntax Peter Achberger implemented in 4.2.0
0012 Abstract classes Aleksandr Kuzmenko implemented in 4.2.0
0013 Default type parameters Ben Merckx implemented in 4.3.0
0014 Self access for abstracts Mark Knol implemented in 4.3.0
0015 Local static variables YellowAfterlife implemented in 4.3.0
0016 Null coalescing operator RblSb implemented in 4.3.0
0017 Null-safe navigation operator Robert Borghese implemented in 4.3.0
0018 Number separators Marcelo Silva Nascimento Mancini implemented in 4.3.0
0019 Numeric literal suffixes Aidan Lee implemented in 4.3.0

About proposals

Haxe Proposals (HXP) can be submitted by any Haxe team developer or community member, as long as it's complete and well explained (please see the "How to submit an HXP" section below).

Once a HXP has been submitted, it can be discussed and modified. Anybody can also submit a PR against an existing HXP to have it amended.

Please understand that the HXP discussion and voting process is for cases where the core team is not opposed to the proposed changes. The team internally discusses all proposals; if they are opposed to a given HXP then it may be rejected with very little public discussion in the PR comments. There is simply not enough time for the core team to provide detailed written rationale for every proposed change which they think would not be a good overall fit for Haxe.

After the HXP has been discussed, a formal vote can take place to accept it. Only Haxe Core Team members are allowed to vote:

To be accepted the HXP needs half + 1 votes in favor of it.

In order to keep the long term goals and vision of Haxe, Nicolas can veto any accepted proposal after the vote, but will explain his reasoning for doing so in details and agrees to use this power with care.

If the HXP is accepted, the core team will work on implementing it.

What needs a proposal?

Stuff that doesn't need a formal proposal (unless it's something fundamental):

  • bugfixes
  • optimizations
  • documentation
  • minor API additions

Stuff that most probably needs a formal proposal:

  • language changes, including adding new features
  • breaking standard library changes
  • large standard library additions (new toplevel types are also considered "large")
  • significant compiler architecture or build process changes

Basically, everything that needs some design process and consensus among the developers is a candidate for a proposal.

How to submit an HXP

  1. Fork the repo, copy the 0000-template.md to proposals/0000-short-name.md, where short-name is a descriptive filename for the proposal document. Don't assign the number yet.
  2. Carefully fill in all sections of the proposal. Pay attention to details: it should show your understanding of the issue and the impact of the proposed design.
  3. Submit a pull request with the proposal. In this PR, Haxe team and the community can provide feedback for it. Be prepared to react accordingly and revise the proposal document.
  4. After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.
  5. Active proposals are to be further discussed in details by the Haxe developer team and finally implemented.

Voting process

It's the responsibility of the author of a proposal to start the voting process.

Once discussion is exhausted, the author of a proposal can request the voting. Following requirements should be met:

  • All questions asked by the core members of Haxe Foundation to the author are answered;
  • The last edit to a proposal was made at least two weeks ago;
  • The last message in the discussion was posted at least two weeks ago.

To start the voting process the author should post the comment:

Request for voting.

Additionally, the author can tag voters in this comment to draw their attention (example).

After this comment is posted the discussion will be locked by any Haxe Foundation member with write access to the haxe-evolution repository. From that point only voters will be able to post comments to the discussion.

About

Repository for maintaining proposal for changes to the Haxe programming language

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published