-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Merge priorities #829
Conversation
d5e62a1
to
35607f5
Compare
failed with a `non mergeable fields` error, because merging being symmetric, it | ||
doesn't know how to combine `1` and `2` in a generic and meaningful way. | ||
evaluates to `{foo = 2}`. A default value is just a special case of a priority, | ||
being the lowest possible one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the implementationementation doesn't manage as such, may we say it is like having -inf
value? Actually, how nickel manage infinites?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Infinite can't be represented as a float literal (they can be obtained by operations on float, I guess, but not written down), so +inf
and -inf
aren't currently possible as numeral priorities. I don't know, is it really that clearer to say that it is -inf
, rather than spelling out loud "this is the lowest possible priority"? To me the latter requires less maths notion (arguably, +inf
and -inf
are not exactly rocket science, but still). I don't have a strong opinion, honestly.
Dually, values with the `force` annotation are given the highest priority. Such | ||
a value can never be overriden, and will either take precedence over another | ||
value or be tentatively merged if the other value is forcing as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same idea as default but with +inf
here.
.with_labels(labels)] | ||
.with_labels(labels) | ||
.with_notes(vec![String::from( | ||
"Both values have the same merge priority but they can't be combined", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Both values have the same merge priority but they can't be combined", | |
"Both values have the same merge priority so they can't be combined", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep the but
. Two values with the same priority may very well be combined, like records. Here the problem is that they have the same priority AND we don't know how to merge them.
priority: MergePriority::Normal, | ||
priority: MergePriority::Neutral, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative could be to use Option<float>
.
then Bottom
become Some(-float::inf())
, Top
become Some(float::inf())
, and Neutral
become None
Sorry not sure how to write infinite in Rust but that's the idea.
May easy the priority comparaisons but may be less clear in the code... Also is harder to pretty print, even it can be managed anyway.
value: Some(t), | ||
.. | ||
} if selected_attrs.value => { | ||
renderer.write_metadata(out, "priority", &format!("{}", n))?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
an improvement could be to check 0 equality and don't print anything if it's the case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, because 0.0
may have been written down. We could check for Neutral
though. On the other hand, it can be useful to know the actual priority, even if it hasn't been annotated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nice improvement for nickel with a clear implementation :)
Only a few changes proposed.
Just to be sure, are we really not needing Merge
token anymore? maybe for RFC001 (custom merge functions)?
Ah yes, good catch. Will drop this commit. |
2c365e5
to
b8168d7
Compare
Co-authored-by: francois-caddet <francois.caddet@icloud.com>
b8168d7
to
9c7e7b5
Compare
This PR depends on #198. Implement merge priorities as of RFC001. The special operator
default rec
andforce rec
are not implemented in this PR but left as future work.