search

erlang / eep

Erlang Enhancement Proposals
http://www.erlang.org/erlang-enhancement-proposals/
264 stars 67 forks source link

Add EEP for experimental features #39

Closed lisztspace closed 2 years ago

lisztspace commented 2 years ago

Add EEP describing support for experimental features in Erlang/OTP

ferd commented 2 years ago

This has been merged fast, but I would recommend putting in more weight towards the configuration formats that can be represented as {enable_feature, true | false, Name} or some variation thereof because those can be put in a proplist (or a map) and automatically allow to set or override preferences by following the specification order.

By comparison, code that can use both {enable, X} or {disable, X} and multiple variations will instead require pre-/post-processing by tools to properly allow mergeable configuration formats.

lisztspace commented 2 years ago

My bad, it shouldn't have been merged directly.

I agree that changing the internal format to something like you suggest is a good idea and will give it some thought. For erlc, using -enable-feature and -disable-feature might be preferred for readability. I already have some code that uses the ordering, of course.

ferd commented 2 years ago

Yeah, I think that's fine, I'm more concerned about the format passed to the compiler module, which I assume the CLI can translate however it wants. Transparently, this is because of challenges in making a more general option-merging mechanism for rebar3 profiles with erl_opts configuration values. But I'm sure that in general, other tools may end up with similar issues in the long run.

lisztspace commented 2 years ago

Note: I've created a new PR (https://github.com/erlang/eep/pull/40) to for better discussions on this.

We have internally discussed using {feature, enable | disable, name} as the compiler option since it aligns better with the module directive -feature(enable | disable, name).