support `--opt:lto,release,danger,strip`, typesafe and user config-friendly alternative to `-d:danger`+friends

timotheecour commented 3 years ago

proposal:

extend --opt to support additional arguments: lto, strip, release, danger. This effectively turns lto,release,danger,strip into proper flags, like the rest (--experimental, --hint etc).
arguments can be negated in the same way as already done with --hint:foo, using sequential processing, eg: --opt:lto --opt:lto:off would result in no lto, whereas --opt:lto:off --opt:lto would result in lto.
optional sugar: allow comma separated arguments, eg: --opt:lto,strip,danger
introspection: code can query for those flags using compileOption("opt", "lto") etc. Existing code using defined(release) would continue to work, so that --opt:release would imply defined(release)

example

nim --opt:lto,danger --opt:lto:off results in --opt:strip

static:
  doAssert compileOption("opt", "danger")
  doAssert not compileOption("opt", "lto")

rationale

type safety you get CT error when a flag has a typo, both with --opt:foo and compileOption("opt", "foo"). --opt introduces its own scoping, avoiding the need for a nim prefix in defined(nimLto) + friends
discoverability all supported values are listed in nim --fullhelp, just like for --experimental
works with user config and command line, unlike -d:release, -d:lto, -d:strip + friends: would fix https://github.com/nim-lang/Nim/pull/15614#issuecomment-712343858 (lto and strip) would fix https://github.com/nim-lang/Nim/issues/14272 would fix https://github.com/nim-lang/Nim/issues/12349

Araq commented 3 years ago

"-d:release -d:danger don't work as expected in user configs" is really a bad gotcha that we should fix somehow. Unfortunately adding opt doesn't "fix" it at all.

timotheecour commented 3 years ago

it would provide a viable workaround, a user would use: --opt:danger in his config instead of a non-working -d:danger

Araq commented 3 years ago

The people who know about the workaround are exactly the people who know about the problem and can avoid it... Sometimes you simply have to fix a gotcha, not hack around it.

github-actions[bot] commented 9 months ago

This RFC is stale because it has been open for 1095 days with no activity. Contribute a fix or comment on the issue, or it will be closed in 30 days.

nim-lang / RFCs