Macro functions

[japm]

I miss c++ macros :)

A partial solution for this would be to have a Macro Function.
The only different behavior from a normal function should be that the
return statement of this function must execute the return of the caller.

So this way we have full type safety but also have control of the callers
behavior.

Example

macro T SomeFunc<T>(T a, T b){
     if (a != b)
         return a;
     //No explicit return here, so no return in caller

}

T CallerFunc<T>(T a, T b) {
     SomeFunc(a,b) ; //If a != b CallerFunc returns a here
     //Other stuff
}

[alrz]

I miss c++ macros :)

Nope. I'd rather miss rust macros,

 let john = json!{
      "name": "John Doe",
      "age": 43,
      "phones": [
        "+44 1234567",
        "+44 2345678"
      ]
    };

Looking at the definition, it runs a pattern-match on the actual tokens and produce a data structure.

Oh and it doesn't stop there. There is a macro which accepts C++ code so you can embed C++ directly in a Rust program,

cpp_header!{
    class Foo {
        Foo() {}
    };
}

mind = blown.

[svick]

In my opinion, returning from a method is an important action that should be visible in the method you're returning from. This proposal would hide that.

[japm]

Yes it hides the return code, but this would be a developer
choice.

I would opt for code clarity first.

This way we can refactor a lot of checks done at the beginning of a method
for parameter correctness, that don't add to the methods logic, but besides
than, you end up writing lots of repetitive

void T Foo(T arg1, T arg2, T arg3){
  if (!boolFuncCheck(arg1))
        return something 
  if (!boolFuncCheck(arg2))
        return something 
  if (!boolFuncCheck(arg3))
        return something 
//other stuff
}

that have nothing in common with core function logic and
would be written like

void T Foo(T arg1, T arg2, T arg3){
     checkArg(arg1);
     checkArg(arg2);
     checkArg(arg3);
}

Its clear in this code that we are sanitizing the input at the beginning,
as concise as possible.

And Visual Studio will refactor a block of code with a return inside :)

[HaloFour]

I would opt for code clarity first.

Hiding control statements from the developer would be the antithesis of clarity.

In your example exactly what would this "macro" return? What is the "invalid" value of T for failing argument validation? There simply isn't an answer to that, not one that can be had programmatically anyway. In the vast majority of cases such a method should throw/fail anyway.

[japm]

I oversimplified the example, it can be 100% more clear.

Its like convention over configuration. If you stand with a pattern that
at the beginning of each method you expect argument validation, this code
makes more sense.

And if you also have a pattern for return codes on invalid arguments you cant be more
concise and i think readable than that.

The same happens when checking return codes for functions

[MkazemAkhgary]

if your function is small enough and meets requirements for being inlined, jitter will do so, no worries there. ok apart from stack overhead which can be automatically solved, what else macro provides that other local functions or methods cant provide?

[MkazemAkhgary]

If you stand with a pattern that
at the beginning of each method you expect argument validation, this code
makes more sense.

do you mean separating validation code from method? I don't think that's a good practice because then your code will be chopped into pieces and you have to follow and look for every macro you wrote and see whats going on there.

if you do your self a favor, you would write validation code within the method and you would save your some time instead of trying to figure out whats going on.

a good code formation is good practice. for example. (notice the blank lines. they help to distinguish between each part of method.)

void Method()
{
    // pre conditions.
    
    // main code
    // etc etc...
    
     // post conditions and return.
}

[stuartstein777]

@MkazemAkhgary a bit OT but I hate uncessary blank lines in code files. Everyone seems to have blank lines everywhere though.

[Mafii]

@stuartstein777 they are not

uncessary

They help future readers to intuitively understand what parts of the code belong together, and they help your brain orientate inside the code, by making the code blocks more distinguishable.

Good code uses blank lines, not all over the place, but to logically group code, at least in my opinion.

[HaloFour]

@Mafii

Agreed, they can help break code into "paragraphs of related logic". For example, I'll generally put a blank line after I've validated the method arguments but before I start doing anything else.

[jnm2]

Blank lines in code serve the exact same purpose as the blank lines you use to separate paragraphs in prose.

[chrisrollins]

You can return from the caller by throwing an exception which you would then catch where you want to "return" to. Using this as part of your normal control flow is bad practice, which means that a syntactic sugar for it would be a bad feature.

[gafter]

@chrisrollins

You can return from the caller by throwing an exception which you would then catch where you want to "return" to. Using this as part of your normal control flow is bad practice, which means that a syntactic sugar for it would be a bad feature.

Using goto statements as part of your normal control flow is bad practice, which means that a syntactic sugar for it would be a bad feature. We should therefore remove if, for, foreach, and while statements from the language. </sarcasm> 😉

Seriously, I agree that syntactic sugar for control-flow implemented using exceptions would be a bad idea in any language built atop the CLR. That's because exception handling has very poor performance on the CLR, and it would result in a language feature with horrendous performance. There are other platforms where throwing and catching an exception is extremely efficient (e.g. the Java virtual machine). On such platforms using exceptions to implement some well-structured language constructs is not a bad idea at all.

[chrisrollins]

@gafter It's bad practice regardless of the performance, was my point. Exceptions are designed for error handling, not control flow.

[MkazemAkhgary]

press Control+F, search exception on your browser. first occurrence comes here

You can return from the caller by throwing an exception which you would then catch ...

Ok, I'm not sure how is this macro function related to throwing or catching an exception? macro function is simply a code snippet that gets inlined exactly where it was placed.

[gafter]

Runtime features do not have to be used for exactly what they "were designed for". Otherwise there are many things that we could never do (e.g. see #110, which "abuses" what virtual methods "were designed for"). Language designers can use runtime features in any way that is suitable to implement a language feature. Exceptions in the runtime can be used for anything you want, no matter what they were "designed for". But a language feature that translates to exception handling has to have an appropriate performance profile. That would be a problem on the CLR, which is why we don't do it. We may invest in improving that aspect of CLR performance some day, after which we might consider language features that translate to exception handling.

[chrisrollins]

@MkazemAkhgary the person who posted this proposal said that the only difference in behavior would be that you can return from the caller. I was pointing out that you can already get that behavior but it's not a good practice.

[Joe4evr]

exception handling has very poor performance on the CLR

Out of curiosity, is this poor performance limited to Exception objects specifically? Since the feature to await in catch and finally blocks makes use of the fact that the CLR can throw any kind of object, so it throws an int.

[mikedn]

Out of curiosity, is this poor performance limited to Exception objects specifically?

Throwing an object of any type is an expensive operation. Simply adding a try/catch/finally block to your code may also affect performance (even if no exceptions are never thrown) depending on how capable the JIT compiler is (and there's a good chance that it's not very capable, navigating around various complications exception handling poses isn't trivial).

so it throws an int.

Really? Even if it does that it would be a boxed int, you can't really throw an int.

There are other platforms where throwing and catching an exception is extremely efficient (e.g. the Java virtual machine)

Really? As far as I can tell from a quick experiment that is not the case. Well, maybe they're faster than in .NET but they're still terrible slow.

[gafter]

@mikedn Creating an exception object in Java in a way that captures a stack trace is slow. I suggest you retry your timing experiment with a preallocated exception.

[sharwell]

@mikedn Expanding on what @gafter said, there is a key difference between the way exceptions in the JVM and CLR work. In both cases, the slowest feature of exception handling is the process of capturing a stack trace. The difference is when this occurs:

• In the CLR, exception stack traces are captured when the exception is thrown, and are therefore a permanent part of the performance profile for throw/catch.
• In the JVM, exception stack traces are captured when the exception instance is created, meaning the throw/catch doesn't require this slow operation at all.

In most cases, the CLR and JVM behave equivalently for this aspect. Since exception stacks at the point where an exception is thrown are the most valuable, it's rare and often considered bad practice in Java for code to separate the exception construction from the point of throwing.

I have not compared the impacts of exception filters, or the exception filtering implementation, on the overall performance of exception handling in the CLR. Remember that while this is a new feature for the C# language, it's been a part of the CLR for a long time.

[mikedn]

I suggest you retry your timing experiment with a preallocated exception.

Indeed, that makes a big difference. And so I get to learn some Java implementation details 😄

Creating an exception object in Java in a way that captures a stack trace is slow.

It turns out that there is more to it than that. At least in the example I put together, the JIT (or maybe the java compiler) transformed all the exception cruft into normal flow control:

    final static UnsupportedOperationException uex = new UnsupportedOperationException();

    static void iseven(long i) {
        if ((i & 1) == 0)
            throw uex;
    }

    static int test() {
        int s = 0;
        for (long i = 1; i < 100000000L; i++) {
            try {
                iseven(i);
            } catch (UnsupportedOperationException ex) {
                s++;
            }
        }
        return s;
    }

Now I wonder what would happen if iseven fails to inline...

[HaloFour]

Isn't there still quite a bit of overhead in simply including try/catch even when no exceptions are thrown?

[orthoxerox]

@HaloFour negligible

[AustinBryan]

I miss c++ macros :)

A partial solution for this

The problem being solved here is you missing C++ macros? 😂