search

erlang / eep

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

New EEP: add support for experimental features #40

Closed lisztspace closed 2 years ago

lisztspace commented 2 years ago

New EEP: add support for experimental features

(take 2 to revert premature merge)

ferd commented 2 years ago

Porting my comments from the prior PR:

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.

I am not concerned about the command-line options, more 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.

Regarding the prior PR's comment mentioning {feature, enable | disable, name}, I do like that form better, but I may suggest using {feature, Name, enable | disable} -- for the simple reason that you can sort it in tuple order on the first 2 elements and assume the third value is stable (the option's value), as is the case with {d, Macro, Value}. As a data list, it feels more natural to have a general {Type, Key, Val} ordering, at least to me.

lisztspace commented 2 years ago

As said in my my from the prior PR, the alternative format {feature, enable | disable, name } has been discussed. Your suggestion of swapping argument order to {feature, name, enable | disable} and the motivation is excellent for all the reasons you list. It is also reasonable to change in the same way for the -feature(..) directive.