I am surprised that the compiler doesn't override the value passed in by the calling function. Anyway, accepting that unfortunate behavior I don't think there is going to be anything you can do to guarantee no one will break that.
As far as I am aware, the closest you could come is what you have done. Name it something like _doNotSet
but I would suggest something like _settingThisBreaksTheTool
. Depending on the audience of the code this may be enough to satisfy your needs.
Edit: This link shows how to determine if a value was supplied or not, unfortunately none of the tactics supplied there are going to work for you. Basically they suggest using a known unlikely value (impossible in your case since you won't know the line number or you wouldn't care). Or don't use default values and overload the function. But the [CallerLineNumber]
attribute needs the parameter to be optional to work. Bugger.
Come on Microsoft... Why
This goes into how .Net implements default values for optional parameters. When you specify that a parameter is optional on a function, and call that function with no value something quite special happens during compilation. The code which does not have a value for that parameter is replaced with code which does have a value, the default value.
I read a few blog posts on this awhile ago, this was the simplest to understand the basics.
I may be making a few jumps here but my guess is that the [CallerLineNumber]
attribute signals the compiler to use a different value, namely the line number. But the compiler won't even go through the process to inject values since there was a value in the first place.
Probably Microsoft would like the [CallerLineNumber]
to override the value passed into the function, but the side affect of piggybacking default values probably caused them to not be able to support that. I will be interesting to see if the Roslyn project brings some enhancements with that function.