Add proposal for using aliases allowing type parameters and additional target types #4452
Conversation
| ``` | ||
|
|
||
| A partially bound type is not valid. | ||
| The `using` aliases below are both valid, and the use of `MyList<>` is valid because the expansion `List<>` is an unbound type, but the use of `MyDictionary<>` invalid because `Dictionary<string,>` is a partially bound type. |
There was a problem hiding this comment.
Consider adding an example of a valid use of MyDictionary. This section is still starting with the words "A partially bound type is not valid.", which doesn't really address the confusion.
| static void F<T>(Option<T> t) { ... } // error: 'T' must be value type in 'Nullable<T>' | ||
| ``` | ||
|
|
||
| However, without explicit constraints, the compiler will treat `T?` as `Nullable<T>` in an alias target which means nullable reference types cannot be used with type parameters in aliases. |
There was a problem hiding this comment.
Should we even permit T? at all? Or if we do, is this line even true? If we view these as macros, then T? will mean whatever T? would mean to the final expansion, not anything predefined like Nullable<T>. For example, using MyMap<T> = Dictionary<T, T?>; would cause different expansions for int and string, where one would be mapped to int? and one would be mapped to string?.
| using Option<T> = System.Nullable<T> where T : struct; | ||
| ``` | ||
|
|
||
| Explicit constraints would also allow restricting the use of the target type. |
There was a problem hiding this comment.
Consider referencing the LDM today, notes are up: https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-02-22.md
This comment has been minimized.
This comment has been minimized.
|
@sylveon I've hid your post for being off topic to this pr. If you would like other features added to the language, please use github-discussions to open the topic. Thanks. |
|
But I was told by @tannergooding to raise this concern here... |
|
@CyrusNajmabadi, I think the question here was on topic. Its a question that directly relates to the feature being exposed here and if a somewhat common ask is being considered or is out of scope If nothing else, having it being called out in the doc as out of scope covers the consideration. |
|
I don't think proposals are the place to tack on general questions/requests for other features. That's what discussions are for. A mechanism to export an alias is an entirely new thing and needs to be discussed and potentially championed first. |
I don' think the ask was to export an alias (e.g. what's covered under namepsace MyNamespace
{
global using Alias = Name;
}This is a specific concern around global aliases leading to increased pollution of the global namespace and thereby increasing the number of conflicts and other potential issues you can run into. The pollution bit is a legitimate concern/consideration that directly relates to what's being proposed. The question about if scoping is or has been considered relates to the "most obvious" solution around mitigating that direct problem. e.g. If I as a package author decide to ship some global aliases (for whatever reason) in my NuGet package (either via the MSBuild support or an implicitly included source file); what problems is that going to cause and has this been considered from the language side of things.
This was already immediately visible with the new |
|
I pinged you in the .NET Evolution Discord to continue the discussion to avoid polluting the PR further :) |
No description provided.