undesirable behavior of @protect_ignore:
I was wrong here:
The original use case that lead to @protect_ignore: was to allow
scripts to pre-pend fhicl definitions to an existing config file.
Sometimes a config file needs to be handled by more than one script.
Just like the default binding operator allows to use
a : 3 a : 2 a : 1
to get a==1 without an error, the "prepending" binding should allow
b @protect_ignore: 1 b @protect_ignore: 2 b : 3
to get b==1 without an error. The current implementation
throws a "Protection violation" error on such use.
#2 Updated by Christopher Green over 4 years ago
We propose the following behavior (old behavior, new behavior):
Please let us know if this is acceptable to you.
#3 Updated by Andrei Gaponenko over 4 years ago
I'll spell out my reading of the table to make sure we interpret it in
the same way. For non-qualified definitions, "replace" in the table
means the traditional behavior - "the last definition wins". Any
conflicting definitions involving @protect_error give an error - I
think that makes sense. If a value is first defined with
@protect_ignore, a subsequent non-qualified or @protect_ignore
definition should be ignored, so we have "the first definition wins"
rule. Yes, this is what I am asking for. Finally, the table suggests
to make it en error to define a value with no qualifiers, then attempt
to override it downstream with @protect_ignore. I have no strong
opinion on this one. I think the suggested behavior is fine.