write system.abs in nim, not magic #485
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
refs #476 (comment)
subtlety
before PR,
nim r main
does't raiseafter PR,
nim r main
raisesOverflowDefect
becauseabs
is now a regular proc.note, if i change
abs
to a template, this would preserve pre-existing behavior, ie not raise here.vs:
note
if we want to make an inner proc (eg abs) be affected by a pragma (eg
overflowChecks:off
), there are 2 ways:overflowChecks:off
, so that 2 distinct procs could end up being instantiated in the same program: one withoverflowChecks:on
and one withoverflowChecks:off
note 2
global flags
-d:danger
aren't affected by this, this is just regarding semantics for a local{.push overflowChecks: off.}
note 3
maybe implicitly generic idea (depending on "environment") could be used in other contexts, eg to generate 2 distinct procs depending on whether we're in vm or not (eg for improving nimvm semantics)