I know that “Sub” stands for “Sub procedure”, but as a function is called “Function” instead of “Func”, I would like to use “Procedure / End Procedure” as an alternative for “Sub / End Sub”.
Hmm. what does this gain though, really?
Only for readability. I always found “Sub” an unclear keyword, where the rest of VB keywords are mostly spot-on (eg. “Overridable” instead of “virtual”).
Certainly not high priority …
I was trying to stay out of this one 
No, I don’t agree.
It’s longer, so more typing and procedure is Pascal. not Basic.
1 Like
But, it can not do harm.
How much work is it?
why not stay consistant with ‘method’?
1 Like
Not much work, i’d expect, but i’m wary about just adding new keywords willy-nilly without tangible benefit. Flor better or worse, established languages have their keywords for things — be int func in Swift or Sub/Function in Visual Basic. Who are we to say, “this keyword for it isn’t nice, let’s use another”?
For Oxygene, when we introduced method, it had a significant benefit for breaking existing Pascal conventions: the main point wasn’t;'t that it was the better word (though it is, so thats a side benefit), but that it broke the dichotomy of treating a method with result and one without as entirely different things. Replacing Sub with Procedure doesnt achieve that — all it does is adds an (arguably better or worse, depending largely on taste) different word for the same thing.
Side note: we did consider allowing Sub to be used for all methods, but unfortunately at least for lambdas there are ambiguities that did not allow that :(.
So my gut feeling is to say this is not worth doing.
2 Likes
The following reaction is not a rant, but simply my personal opinion … 
I really don’t understand why naming functions and procedures the same (“method”) can be a good thing. I personally hate that. I have to look at if a method has a return type to know if it’s a function or not. In C# I have to look for a method that has the same name as its containing class to know if it’s a constructor. I can go on with this.
I personally think readability is much more important than being concise. That’s why, in VB, I always use the Call keyword when invoking a procedure. That’s why I always use named arguments, especially when they’re booleans. My former employee disallowed that, because “you can hover your mouse over the argument and see what it is” (…).
The “Sub” keyword is coming from “GOSUB”. In a class it’s not a subprocedure, because it’s not contained in an other procedure.
I like VB/Mercury, because imho it’s the language with the best readable syntax. It can even be better by improving on things like calling a sub a procedure.
I’m ok with my suggestion don’t being honored. It’s just a suggestion based on (you’re right) my personal taste :).
What makes the return type special? You also have to look at a method to see if it takes parameters? Should there bet a different word for methods that take parameters than for methods that don’t? What makes the (lack of) return type different?
note that many methods with return types are not functions in the literal sense, as that they calculate a value and return it. how is a method that performs an action and returns a success value different (enough) than a method that performs an action and does not return a success value to warrant an entirely different language construct name?
No disagreement here that that syntax sucks. Thats (also also so we can support named .ctors) is why we allow “this” to be used in our C# dialect
Agreed. but distinguishing methods that (can) return a result from those that don’t IMHO doesnt add readability. its an entirely arbitrary distinction.
I hear you. To me, many things VB does look silly and are entirely driven by history. But how many do we change just because we don;'t like the name, and at what point is it still VB? For example, does the “Dim” keyword make sense to declare (non-array) variables? i’d say no, absolutely not. But if we change to to Var, is it still VB, or are we creating a more awkward version of Pascal?
As I remember correctly, this has also been added to Mercury.
the named part, yes. we didn’t have to change the core syntax (“New”) as that was already compatible.
https://docs.elementscompiler.com/Mercury/LanguageExtensions/MultiPartMethodNames/
Oké one more reaction. Not to try to get it in, but just for the sake of mild disagreement … 
For me a function calculates/generates something and then returns the result. A procedure just performs a task. Now I think about it, an even better keyword would be “Action”, but let’s not go in that one …
Arguments don’t change what something is.
In T-SQL you have also a differentiation between function and procedure.
If you’re ever going to do that, you can expect a suggestion from me asking for “Declare” instead
Apart from this discussion, I’m very happy with what you’re doing with Mercury. Glad that you bring VB back to live
That’s it. There are far more important “problems” than this :). And BTW, luckily Oxygene still has functions and procedures 
1 Like
Yes, and that’d be fine if all “functions” did that. but most/many methods don’t, in modern APIs. You change a “procedure” to return a bool, and suddenly you need to change the keyword used to declare it? why?
FWIW, Oxygene still supports function and procedure so if you prefer, you can use those there keywords to “mark” your methods as logically being “functions”, if you prefer.
Glad to hear! 
2 Likes