C# preprocessor directives #define

[srburton]

I'm very sorry for the lack of such functionality for .net core packages, it would be a good to have defines within methods so that we can kind of give paths to third-party programmers who use libraries.

Functionality

Should the above need not be satisfactory the pre processor will

Satisfactory need

[YairHalberstadt]

Do you know of any language where this feature does exist?
This is not how #define works in c++ for example.
It's also unclear how this would work for control flows which cannot be statically verified to call one method before another.

[HaloFour]

I'm not sure I understand this proposal. Are you asking for preprocessors which would affect the runtime of the compiled assembly via some kind of state? That is certainly not what preprocessors are intended to do. They are parsed and processed before the syntax of the code. They are independent of the concept of classes or methods.

This sounds like a perfect task for a custom analyzer and some attributes and not for the language itself.

[YairHalberstadt]

Note also that exceptions are runtime behaviour, so I don't see how they could error in the preprocessor.

[srburton]

I think it would be more an intelisense of Visual Studio, do not know for sure yet, it would be good for other programmers to kind of give the way so that it did not have such a great learning curve of third libraries, Da to think of better solutions to get On a nice level of that suggestion.

[theunrepentantgeek]

It's also worth noting that there is usually (though not always) a way to design classes to eliminate this kind of temporal coupling, making it impossible (or, difficult) to use the class in the wrong way.

[srburton]

I agree with you, but this idea would be for SDK that are closed. It would be a great implementation because Inintellisense itself took you to a happy place.

[yaakov-h]

The basics could be done with two attributes and an analyser, but complex flow analysis becomes difficult or impossible:

public void Foo(Test t)
{
    t.MethodTwo(); // Should this have a warning?
}

[srburton]

What could be done is also a JSON that intelissense can read and interpret.
Let's assume a json of happy paths and possibility.

public class Test
{
   
    public void MyMethodOne()
    {
      
    }

    public void MyMethodTwo()
    {
      
    }
    public void MyMethodThree()
    {
      
    }
    public void MyMethodFour()
    {
      
    }
}

Json example Possibilities

{
     "mynamespace.project.MyClass.myMethodOne":{
           "mynamespace.project.MyClass.MyMethodTwo",
           "mynamespace.project.MyClass.MyMethodFour":{
            "mynamespace.project.MyClass.MyMethodThree"
          }	 
      }
}

**Case success**

public class Test
{

public void Main()
{   
  
    var t =  new Test();
    t.MyMethodOne();
    t.MyMethodTwo();
    t.MyMethodFour();  
    t.MyMethodThree() // <<<<<<<<<<
}

}

[rubenwe]

Just use a fluid design where methods return types are interfaces only allowing methods that are valid to call based on the state of the returned object.

Look at enumerable.OrderBy(...).ThenBy(...) as an example of how this can be done.

[Austin-bryan]

Preprocessor literally means "processing before" as in "before the rest of the code." This is not preprocessing, so it won't work the way you think it would. Even if it did, there is likely a better way to design your code anyhow.

[DavidArno]

To illustrate how @rubenwe's suggestion works, consider the following code:

public interface IMethodTwoProvider
{
    IMethodThreeProvider MyMethodTwo();
}

public interface IMethodThreeProvider
{
    IMethodFourProvider MyMethodThree();
}

public interface IMethodFourProvider
{
    void MyMethodFour();
}

public class Test : IMethodTwoProvider, IMethodThreeProvider, IMethodFourProvider
{
   
    public IMethodTwoProvider MyMethodOne()
    {
        return this;
    }

    IMethodThreeProvider IMethodTwoProvider.MyMethodTwo()
    {
        return this;
    }

    IMethodFourProvider IMethodThreeProvider.MyMethodThree()
    {
        return this;
    }
    
    void IMethodFourProvider.MyMethodFour()
    {
      
    }
}

public static class Prog
{
    static void Main()
    {
        var test = new Test();
        test.MyMethodOne().MyMethodTwo().MyMethodThree().MyMethodFour(); // <- valid code
        test.MyMethodTwo(); // <- error, MyMethodTwo is not accessible.
    }
}

To access MyMethodTwo, MyMethodOne must be called first and MyMethodTwo is then accessible from the returned value.

[juliusfriedman]

Yea, I can really see this!

Was just working on come C++ where is had to #pragma and #define (albeit not exactly as you outline.. [th. Ntl]) and I was like C# is really missing this feature...

[YairHalberstadt]

@juliusfriedman
This proposal has nothing to with c++ preprocessor directives. If you do want them, I suggest you create a new feature request.

[juliusfriedman]

Why don't you outline and explain then what the ask is... by all means to simplify the reading efforts if nothing else

[YairHalberstadt]

Because I didn't write this proposal, and it is a fundamentally impossible one anyway.

[juliusfriedman]

In that case let's not infer so much either from the proposal or each other.

[juliusfriedman]

And also try a static GetType().GetMethods(flags).Select(mi=>mi.Name) and put that in a HashSet string with case insensitive string comparer.... no need for a preprocessor directive to do that for you. Also consider that keeping the method info around has greater uses than just the proposed define syntax.

Perhaps it would be useful to allow more types and expressions on a define statement but that's a different proposal I suppose... not to mention you can represent almost anything with int and enough effort.

There is also expressions and the emit all and yet finally, I also think you can achieve this with use of partial on the method declaration, @jskeet, (Here) He has an article on sideways overloading which can already do this although not with different method names yet one would still be able to combine the approaches.

[The-Futurist]

I've worked on huge systems written in C and the presence and semantics of #define are often a source of bugs or confusion. C# history of avoiding this is IMHO a wise choice.