Auto Functions - Suggestion

[jcouv]

@MichaelPuckett2 commented on Thu Sep 21 2017

7.1 suggested for 7.2 or later:

Allow a function to auto declare and return a value.:

Existing format example:

    public bool Navigate(Type sourcePageType)
    {
        var success = false;
        if (Application.Current is INavigate navigator)
        {
            success = navigator.Navigate(sourcePageType);

            if (success)
                CurrentPage = sourcePageType;
        }
        return success;
    }

Suggested format example:

    public bool Navigate(Type sourcePageType) as success
    {
        if (Application.Current is INavigate navigator)
        {
            success = navigator.Navigate(sourcePageType);

            if (success)
                CurrentPage = sourcePageType;
        }
    }

In the suggested format the function automatically initializes a value for success and will automatically return that value whenever return is called. In this method you can avoid declaring the variable and returning it when we know this will be the behavior anyway. Thoughts?

---

@dpoeschl commented on Thu Sep 21 2017

Hi @MichaelPuckett2, this feature request would probably make more sense over on https://github.com/dotnet/csharplang/issues. Can you port it there?

---

@jcouv commented on Sat Oct 21 2017

Moving the issue to csharplang.

[jnm2]

Very similar to: #142, #808

[MkazemAkhgary]

this makes return paths of methods very unclear and harder to understand.

[MichaelPuckett2]

I might agree but I'm wondering if you overlooked the function syntax... In my example it states 'as success' right in the function header. This not only initializes the variable but explains exactly what it is returning. Maybe it's just different to look at to different people so I'm not saying you're wrong at all but I feel like personally it's even more clear from the start what is being returned. It basically borrows from the concept of initializing out or if variables inline also, which I am also a huge fan of, so I feel this not only compliments the syntax but makes it easier to use. Please don't read this as me saying you're wrong to not like it or think it's harder to read because it may very well be to some. I have a strong liking to linq, lambda, and functional programming in general so my views may not be the same as others. That said, it still feels like an easier enough addition to the language right? Whether all adopt to use it or not?

[DavidArno]

public bool Navigate(Type sourcePageType)
{
    var success = Application.Current is INavigate navigator &&
                  navigator.Navigate(sourcePageType);

    if (success) CurrentPage = sourcePageType;

    return success;
}

Problem solved.

[svick]

@MichaelPuckett2

That said, it still feels like an easier enough addition to the language right? Whether all adopt to use it or not?

If every "easy addition" was actually added to the language, you would end up with terrible, confusing language. C# is already plenty complicated, any additions, especially syntax sugar, have to be really worth it.

[MichaelPuckett2]

public bool Navigate(Type sourcePageType) => (Application.Current is INavigate navigator && navigator.Navigate(sourcePageType)).Switch(() => CurrentPage = sourcePageType, null);

@DavidArno Problem Solved again... It's just not as elegant but we can continue morphing this into different methods of doing it if you like.

@svick Apologies man; I thought you knew that C# was a progressively growing language where syntactic sugar is one of the reasons it's chosen. Like var, linq, lambda, tuples, out variables, pattern matching, deconstruction, local functions, async await, and I don't need to go on because we all already know.

Look, I don't mind if you guys have different opinions about the suggestion, that's why it was just a suggestion, but coming up with slightly arrogant or rude reasons isn't the right way to go about it. It was a neat idea, it seems to work, and from a logical stand point to me it make better sense. If you don't agree I completely understand and no hard feelings but I could argue many reasons why half the features in C# don't need to be there at all... The fact is; I actually like the features and the syntactic sugar in C# and wouldn't want to argue against them. I've been using C# since it was released and I work with Java and JavaScript and I've just recently gotten my toes wet with Kotlin. I have also used C, C++, and C++.NET, so the C in general syntax I really like. However; I have also written in Python, F#, VB.NET, PHP, Razor, SQL, and so on so I have a craving for the best of all worlds. My experience in software development is not young and I don't mind being shut down or not excepted as a suggestion, but I can easily defend my reasoning and logic if I need to against rudely objective remarks.

To my suggestion here's what I see is happening and if you agree fine and if not fine:

• It's less code. Although less code isn't always as easy to debug (step through) or read this gives you the freedom to do both. There's nothing stopping us from adding break points and there's nothing that makes it unclear what is happening.
• It auto initializes and sets up the value to be returned where the logic of the function would be to whatever is needed and adjust that value if needed.
• It cleans up a very common situation where many 'team oriented developers' will 'intentionally' break out code so that it can be stepped through and easily read and understood by peer reviews.

That's all I'm saying and I'd appreciate it if anyone else reading this would give it just a little thought before beating me down.

[svick]

@MichaelPuckett2

Apologies man; I thought you knew that C# was a progressively growing language where syntactic sugar is one of the reasons it's chosen. Like var, linq, lambda, tuples, out variables, pattern matching, deconstruction, local functions, async await, and I don't need to go on because we all already know.

Those features were not added because doing so was easy. They were added because their usefulness outweighed making the language more complex. Personally (and yes, it's just my opinion), I don't think this feature would do that.

It's less code.

It's slightly less code.

It auto initializes and sets up the value to be returned

I don't like that. I like that C# forces me to explicitly specify initial values of local variables. (Sure, it doesn't require that for fields and auto-properties, so it's not unprecedented, but that doesn't change my opinion.)

It cleans up a very common situation

I'm not convinced it's that common.

---

It's your proposal and it's up to you to convince the community and, more importantly, the language design committee, that it's a good one. I'm not sure telling people that they overlooked something, that they don't know how the language changed, implying that they didn't think enough about this or listing your accomplishments is the best way to do that.