Preprocessor directives to check for existence of types and members

[verelpode]

I suggest enhancing the conditional compilation directives (AKA preprocessor directives) to support compile-time checking of the existence of types and members, instead of the common-but-problematic technique of checking for particular version numbers of .NET Framework etc.

To check if a class/struct/interface/enum/delegate/type exists, I suggest:

#if TypeExists(System.Text.Rune)

To check if a generic type exists:

#if TypeExists(System.Collections.Generic.IReadOnlyDictionary<,>)
    System.Type t = typeof(System.Collections.Generic.IReadOnlyDictionary<,>);
#else
    System.Type t = typeof(System.Collections.Generic.IDictionary<,>);
#endif

To check if a property exists:

#if PropertyGetterExists(System.Text.StringBuilder.MaxCapacity)
#if PropertySetterExists(System.Text.StringBuilder.MaxCapacity)
#if PropertyInitializerExists(System.Text.StringBuilder.MaxCapacity)

Alternatively, if you prefer:

#if PropertyExists(System.Text.StringBuilder.MaxCapacity, get)
#if PropertyExists(System.Text.StringBuilder.MaxCapacity, set)
#if PropertyExists(System.Text.StringBuilder.MaxCapacity, init)

To check for a property in a generic type:

#if PropertyGetterExists(System.Collections.Generic.Dictionary<,>.MaxCapacity)

To check if an event exists:

#if EventExists(System.ComponentModel.INotifyPropertyChanging.PropertyChanging)

To check if a field exists:

#if FieldExists(System.Numerics.Matrix3x2.M11)

To check if a method exists:

#if MethodExists(System.Text.StringBuilder.GetChunks())
#if MethodExists(System.Text.StringBuilder.StringBuilder.Insert(int, ReadOnlySpan<char>))
#if MethodExists(System.Text.StringBuilder.StringBuilder.Insert(int index, System.ReadOnlySpan<char> value))

MethodExists would check for a particular overload of the method, thus specifying the method signature (parameter types) would be required. The parameter names would be optional, but if the names are specified, then MethodExists would only return true if the parameter names exactly match, thereby ensuring that the correct method is truly detected.

To check if a particular constructor method exists:

#if ConstructorExists(System.Text.StringBuilder(string value, int startIndex, int length, int capacity))

To check if a particular member of an enum exists:

#if EnumMemberExists(Windows.UI.Xaml.Visibility.Hidden)

To check if a namespace exists:

#if NamespaceExists(System.Text.Json)

The fact that #if x is an expression would remain unchanged, thus this example would be valid:

#if TypeExists(System.Text.Rune) && TypeExists(System.Text.Json.JsonDocument)

These new conditional compilation functions (TypeExists etc) would eliminate the frequent problem of incorrectly used symbols. I often see incorrect usage of conditional compilation symbols, for example:

#if NET48 || NET45
    ...
#else
    ...
#endif

This problem is especially common because, unlike C++, C# only allows a conditional compilation symbol to have a boolean value not an integer. Thus C++ but not C# supports:

#if NETDOTVERSION >= 5.0

However, even if the above version comparison were supported, it's still not the right way. Microsoft recommends to check for specific features, not to check for specific version numbers of the OS or .NET Framework etc. However often we're forced to check for specific version numbers anyway because no better solution exists. The suggested new conditional compilation functions (TypeExists etc) would allow us to test for the existence of specific classes etc instead of the bad way of checking for specific version numbers.

By the way, it's great to see how the staff have improved the way that C# language ideas and proposals are posted in GitHub. In my opinion, this was a very necessary improvement to procedures, so I'm really glad to see it has now been done. This new way should help reduce the problem that existed previously; the problem where people posted ideas and then received pseudo-inappropriate replies from a small handful of hardcore participants who were not even staff members yet talked with such authority that people were misled into thinking that they were discussing with staff when in reality they were discussing with merely peers not staff. The small handful of hardcore participants was very offputting. It's great to see that staff have already taken steps to solve this problem.

For example, someone would post an idea, just an idea, and then a hardcore participant would very nearly/practically reply like:

"Why should I create what you want? Convince me."

And then the member of the public was left wondering:

"Huh? It was just an idea for discussion. I wasn't demanding anything. Hey wait a minute, you're not even a staff member! Or are you? Who are you to speak with such authority? What on earth is going on in this repo? I can't figure this out, I'll just leave this repo to this odd small handful of hardcore participants. It looks like the staff have also abandoned this repo already."

Hardcore fans destroy or damage the object of their admiration. But that's the past! It's now great to see that staff implemented changes to procedures to solve the problem of a small handful of hardcore participants/fans driving away most other "normal" participants.

The chicken-and-egg problem

(Edited. I added this after @Phantonia raised a very good point.)
To solve the chicken-and-egg problem of determining whether a type or member exists while simultaneously compiling or analyzing the same source code, it would be reasonable to solve this by saying that #if TypeExists(x) etc will only work with external/referenced Assemblies/DLL's/metadata, not with the same code as currently being compiled.

For example, if your app references/uses .NET Framework, then your app could use #if TypeExists(x) to check if type x exists in .NET Framework or any other Assembly that your app references/uses, but your app cannot use it to check if type x exists within your app.

Additionally, it would only work with fully-qualified names. C# using statements would have no effect on these new #if directives. Thus you could write #if TypeExists(System.Text.Rune) but you could not write #if TypeExists(Rune) regardless of whether you wrote using System.Text; anywhere in the .cs file.

[Phantonia]

I believe for this proposal to be implemented, a lot about how the compiler works would have to be changed. To my knowledge, normal #if directives are resolved during lexical analysis. At that point, the compiler doesn't know anything about types, properties, methods, etc. For this to work, it would need to carry theses directives until semantical analysis. I don't think it's impossible, but the cost would probably be immense for pretty little gain.

[HaloFour]

The languages that I think of that do this, e.g. JavaScript, do the evaluation at runtime. With the evaluation at compile time this seems like it would only offer little gain since the type/member might not exist at runtime. I do get what it's trying to do, but having the existence of any type/member be a flag vs. having a set number of explicit flags only feels like it would make things more complicated, not less.

[verelpode]

@HaloFour -- Thanks for your comment and feedback. Unfortunately I've decided that I do not wish to reply to any messages from you. Sorry.

[333fred]

@verelpode, I'm not sure where this antagonism is coming from, but it's striking me as pretty unwarranted. There are a number of long-time contributors on this repository who, while not members of the team, have a lot of experience working with the team and do a good job at asking the types of questions we think about when considering proposals. Where people step over the line we do enforce our Code of Conduct, and if you feel that we're missing something feel free to email [email protected]. HaloFour's comment was made in good faith, and while it's your prerogative to ignore his comments, please understand that taking that approach to commenters in general is unlikely to result in proposals that are received well by the team.

[ActivistInvestor]

This feature (or at least a subset that detects if a type exists) would not constitute 'little gain'.

Many of the APIs I develop are designed to act as a layer that sits in between the application developer and one or more very complex underlying APIs that can require years to learn to use effectively, and consist of dozens or even hundreds of assemblies that may need to be referenced from a project.

Some of the APIs I develop support optional functionality that requires additional assemblies to be referenced. If the API user doesn't need that optional functionality, they must still add a reference to the assembly that requires it, which is making things more complicated for my API user, not less complicated.

If I had conditional compilation based on existence of a type (or even less, existence of an assembly), then I can exclude the code that provides the optional functionality, and the API user doesn't have to add a reference to the assembly that requires it when they aren't using the optional functionality. IOW, my objective is to exclude code that my API user doesn't need because if they did need it, they would have to reference the assembly anyways.

So, I think you seem to have it backwards. The feature, if used correctly, serves to make things simpler for the user that I'm developing the API for, not more complicated. The fact that it would make the implementation of my API more complicated is already taken for granted, because the principal purpose of that API is to abstract away the complexity of using several extremely complex underlying APIs that my API sits on top of.

In any case, the original proposal is probably out of the question given when conditional compilation is done, but for my purposes, nothing more than conditional compilation based on whether a specified assembly is referenced, is really all that I need.

[huoyaoyuan]

Some of the APIs I develop support optional functionality that requires additional assemblies to be referenced. If the API user doesn't need that optional functionality, they must still add a reference to the assembly that requires it, which is making things more complicated for my API user, not less complicated.

How does the API user reference the conditionally compiled library?

[ActivistInvestor]

Code that conditionally-compiles would not be referenced from another assembly, it must be included in the project file where it is used.

[333fred]

Thus C++ but not C# supports:

#if NETDOTVERSION >= 5.0

Of note, this is why the BCL team is starting to add _OR_GREATER preprocessor directives: https://github.com/dotnet/designs/blob/main/accepted/2020/or-greater-defines/or-greater-defines.md

[verelpode]

The chicken-and-egg problem

@Phantonia wrote:

normal #if directives are resolved during lexical analysis. At that point, the compiler doesn't know anything about types,

Good point! I thought about how to solve the significant chicken-and-egg problem you mentioned, and I came up with this:
To solve the chicken-and-egg problem of determining whether a type or member exists while simultaneously compiling or analyzing the same source code, it would be reasonable to solve this by saying that #if TypeExists(x) etc will only work with external/referenced Assemblies/DLL's/metadata, not with the same code as currently being compiled.

For example, if your app references/uses .NET Framework, then your app could use #if TypeExists(x) to check if type x exists in .NET Framework or any other Assembly that your app references/uses, but your app cannot use it to check if type x exists within your app.

Additionally, it would only work with fully-qualified names. C# using statements would have no effect on these new #if directives. Thus you could write #if TypeExists(System.Text.Rune) but you could not write #if TypeExists(Rune) regardless of whether you wrote using System.Text; anywhere in the .cs file.

@333fred wrote:

Of note, this is why the BCL team is starting to add _OR_GREATER preprocessor directives

Great! I'm glad they're doing that. I think they should proceed with that, although it doesn't completely solve the problem, considering that actually the recommended technique is to check for the existence of specific features instead of checking version numbers.

[CyrusNajmabadi]

it would be reasonable to solve this by saying that #if TypeExists(x) etc will only work with external/referenced Assemblies/DLL's/metadata, not with the same code as currently being compiled.

I'm not comfortable with the lexer needing any sort of dependency on something like assembly resolution or type binding.

I don't mind a language construct for this. I just don't think it should be in the lexer.

[terrajobst]

I don't mind a language construct for this. I just don't think it should be in the lexer.

If done outside the pre-processor, then yeah, it would be potentially less ugly because using and "regular" binding rules could be used, like:

if_symbol_exists(Dictionary<,>)
{
    int Method(Dictionary<string, int> some)
    {
        if_symbol_exists(Dictionary<string,int>.TryAdd(string, int))
        {
            some.TryAdd("immo", 42);
        }
        else
        {
            if (!some.ContainsKey("immo"))
                some.Add("immo", 42);
        }
    }
}

(I put "regular" in quotes because one can't really reference methods like this in code; the closest thing is overrides but then you're providing a definition.)

But it feels like a heavy hammer for a feature that can be expressed using the pre-processor:

#if NET2_0_OR_GREATER

    int Method(Dictionary<string, int> some)
    {
        #if NETSTANDARD2_0_OR_GREATER || NETCOREAPP2_0_OR_GREATER
            some.TryAdd("immo", 42);
        #elif
            if (!some.ContainsKey("immo"))
                some.Add("immo", 42);
        #endif
    }

#endif

[HaloFour]

(I put "regular" in quotes because one can't really reference methods like this in code; the closest thing is overrides but then you're providing a definition.)

If implementing this feature would enable nameof to reference a specific method overload as well as further opening the door for methodof or infoof then I'd be all for it. 😄

MethodInfo tryAdd = methodof(Dictionary<string,int>.TryAdd(string, int));

[terrajobst]

I agree with @333fred -- we're adding support to allowing pre-processor version checks that can do >=.

In practice, hit testing individual APIs feels extremely noisy to me. And considering the need for using fully qualified names also quite ugly. To me, version checks -- while not ideal -- are the more pragmatic solution. Even for cases like WinRT, where you can do hit testing on individual symbol, we're moving to a version based model that is paired with an analyzer to ensure developers check for the correct version.

[yaakov-h]

For what its worth, the only static/compiled language I know of that has this kind of feature is Swift, which does it based on OS version and not each individual method: https://nshipster.com/available/#available-1

In other languages such as Javascript, Objective-C, etc. this is only possible as a runtime check, which is what I believe Swift actually compiles #available checks into.

.NET offers something very similar with the new platform compatibility attributes (https://docs.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer), but due to the nature of .NET this approach only works for APIs that you already have available, just that they would throw an exception on an unsupported platform. You can't use this to gate against APIs of .NET itself.

Due to the differences in how the SDKs work, though, I don't think its feasible to take the Swift approach here, and I can't think of anything else that would achieve the same effect... other than #if NETWHATEVER_OR_GREATER.