You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This creates a name clash when both attributes need to be used in the same file or even when only one of the attributes is used but both namespaces are imported. Various compilation units in the codebase handle the name clash in various ways: sometimes NotNull for the code analysis is renamed to NotNullOnReturn, and sometimes the DLR NotNull is renamed to NotDynamicNull. If there is no clash but just ambiguity, the attribute may not be renamed at all, just redeclared.
Even when there is no name clash or ambiguity, this is still confusing: when reading the code, it is not immediately obvious which attribute (hence which meaning) is applied. This has been bugging me already for a while.
The issue has been discussed before resulting in a compromise of using NotDynamicNull for the DLR NotNull. This requires renaming the attribute in the prologue of every .cs file where such attribute is used (and it is used frequently). My understanding was that, with time, NotDynamicNull will be supported directly by the DLR and all those renames polluting .cs files could be removed without requiring further changes to the IronPython code. Because this was supposed to be a DLR attribute, that was my reason for rejecting the alternative name NotNoneAttribute.
But now with global using, the whole issue can be easily handled exclusively at the IronPython level; no need to drag DLR into this. As I have stated before, I prefer NotNone over NotDynamicNull, primarily because is as short as NotNull and length matters since this attribute is used in method declarations where most often the whole declaration is put on one line.
Therefore I propose the following solution:
NotNullalways means System.Diagnostics.CodeAnalysis.NotNullAttribute.
Microsoft.Scripting.Runtime.NotNullAttribute is renamed globally to NotNone. The code uses solely the renamed version.
If possible, IronPythonAnalyzer is used to spot usage of not-renamed DLR NotNull.
All existing other aliases for those two attributes are abolished, together with the corresponding file-scope using declarations for those aliases.
The rename of DLR NotNnull is done with global using so that:
It is readilly available without extra file-scope using (this attribute is much more often used than the one for code analysis)
If the DLR ever does change the name for NotNull, it will require update in only one place (per project).
If this proposal gets a go ahead, I am prepared to implement the changes throughout the whole codebase.
The text was updated successfully, but these errors were encountered:
Very cool, didn't know global using was a thing! Sounds good to me, I propose we use the project file version of it (instead of sticking it in a random cs file):
NotNullAttribute
comes from two sources:This creates a name clash when both attributes need to be used in the same file or even when only one of the attributes is used but both namespaces are imported. Various compilation units in the codebase handle the name clash in various ways: sometimes
NotNull
for the code analysis is renamed toNotNullOnReturn
, and sometimes the DLRNotNull
is renamed toNotDynamicNull
. If there is no clash but just ambiguity, the attribute may not be renamed at all, just redeclared.Even when there is no name clash or ambiguity, this is still confusing: when reading the code, it is not immediately obvious which attribute (hence which meaning) is applied. This has been bugging me already for a while.
The issue has been discussed before resulting in a compromise of using
NotDynamicNull
for the DLRNotNull
. This requires renaming the attribute in the prologue of every .cs file where such attribute is used (and it is used frequently). My understanding was that, with time,NotDynamicNull
will be supported directly by the DLR and all those renames polluting .cs files could be removed without requiring further changes to the IronPython code. Because this was supposed to be a DLR attribute, that was my reason for rejecting the alternative nameNotNoneAttribute
.But now with
global using
, the whole issue can be easily handled exclusively at the IronPython level; no need to drag DLR into this. As I have stated before, I preferNotNone
overNotDynamicNull
, primarily because is as short asNotNull
and length matters since this attribute is used in method declarations where most often the whole declaration is put on one line.Therefore I propose the following solution:
NotNull
always meansSystem.Diagnostics.CodeAnalysis.NotNullAttribute
.Microsoft.Scripting.Runtime.NotNullAttribute
is renamed globally toNotNone
. The code uses solely the renamed version.NotNull
.using
declarations for those aliases.NotNnull
is done withglobal using
so that:using
(this attribute is much more often used than the one for code analysis)NotNull
, it will require update in only one place (per project).If this proposal gets a go ahead, I am prepared to implement the changes throughout the whole codebase.
The text was updated successfully, but these errors were encountered: