-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Support non-trailing named arguments with dynamic. #24334
Comments
Tagging @VSadov to advise. |
Yes. We should add some handshake and condutionally enable the scenario. It would be something similar to the “RuntimeFeature” but in dynamic binder. Perhaps simpler - we probably only need the static aspect of it. |
Actually we may add support for ‘in’ argument kind in the binder and use that as a trigger that both ‘in’ arguments and nontrailing names are supported |
Although it feels a bit like hack. More formal “feature X supported” marker like in RuntimeFeature is probably better. |
We should probably allow for It does seem a bit of a hack to use the relevant enum field to indicate support for a feature that could exist without it (indeed, which does exist without it right now), but it's a hack that needs no further API work, and seems it should be dependable. |
As for the nontrailing names - there is no special API to check. And I feel there will be more features like this. The solution could be something like RuntimeFeature , but in namespace Microsoft.CSharp.CompilerServices
{
public static class RuntimeFeature
{
// Presence of the field indicates runtime support
public const string NontrailingNamedArguments = nameof(NontrailingNamedArguments);
// Runtime check
public static bool IsSupported(string feature);
}
}
// Usage
if (RuntimeFeature.IsSupported("SomeNewerFeature")
{
// Use feature when emitting code at runtime (CodeDOM, RefEmit etc)
} |
Sounds good. I will bring this up with LDM first (probably can get it on the agenda for next week). @JonHanna Would you be able to help drive such API on corefx side (once LDM gives thumbs up)? Some thoughts ahead of the corefx/API discussion: |
Sure.
Is it possible to use a more recent version of just Microsoft.CSharp? (I pretty much just use what nuget gives me across the board myself, so don't know from experience) and hence for someone to have support for that version while CompilerServices wouldn't think they should? |
If this can be done from the existing API. I wonder if we should start to namespace the string identifiers a bit, so something like |
There is a way to ensure that the new I don't have a strong opinion on the identifier for this feature, but keep in mind that the pattern for |
Moving to |
Issue moved to dotnet/csharplang #2069 via ZenHub |
Currently with the likes of:
We get CS8324.
Since support for non-trailing named arguments has recently been merged into corefx, ideally roslyn could make use of it, rather than raising that error.
In itself this is simple, but identifying whether it will be supported or not is another matter.
The text was updated successfully, but these errors were encountered: