[Implemented] In and Out parameters

In VB we have ByVal and ByRef.
I’d like to see In and Out added.


Public Sub ByValExample(x As String)
End Sub
'Call as: ByValExample(x)

Public Sub ByRefExample(ByRef x As String)
End Sub
'Call as: ByRefExample(x)

Public Sub InExample(In x As String)
End Sub
'Call as: InExample(x)

Public Sub OutExample(Out x As String)
End Sub
'Call as: OutExample(x)

So no In or Out or Ref in the call.
This makes overloading on variable type impossible, but that is already the case with ByVal and ByRef.

Thanks, logged as bugs://84164

I would suggest using angle brackets ( & ) just like in InAttribute and OutAttribute.

Welcome @fidu

can you give a syntax example of what you mean?
Or do you mean that we should just use the attributes on the parameters?

Oops. My reply got modified a bit. I was suggesting the following:

Public Sub InExample(< In > x As String)
Public Sub OutExample(< Out > x As String)

It is much easier to read the code when angle brackets are used.

That syntax already works automatically/implicitly, since these attributes are defined by the runtime. This feature request is about not needing the attributes, and having a syntax more symmetrical with ByRef, as I understand it…

As @mh said, the Attribute syntax works (although not 100%) in Visual Basic - and thus also in Mercury.
But the syntax is then:

Public Sub InExample(<In>ByRef x As String)
Public Sub OutExample(<Out>ByRef x As String)

Problem with attributes usage is that this is not transparent; attributes to not appear in the CC / Intellisense, so you have to know that this is possible; you won’t get any help from any IDE.

To make this more transparent - with CC help - my suggestion was to introduce the In and Out keywords, that are really only syntax sugar for the attribute syntax.

1 Like

I understand now. In general, I would like to see as little breaking changes as possible compared to VB.NET and only when absolutely necessary. Personally, I would be much more motivated to switch, given that I do not have to learn/relearn a lot.

Promise: We keep the breaking changes to a minimum.
And they will all be documented.

We have a strong background on this: our first language, back when we started in 2004 was Oxygene, an Object Pascal derivative based on Delphi. We’ve evolved Pascal like crazy, even our first release added dozens of new language features over what Delphi had at the time, and we’ve added loads since — see http://elementscompiler.com/oxygene/evolution.

But, with the exception of a few breaking changes we purposely made because we felt they were deign issues with the original Delphi implementation, pretty much all the changes are entirely additive. A Delphi developer can start coding in Oxygene and know the language and feel right t home immediate. They don’t have to learn a single new thing, language wise — but they are anomaly snatching the surface of what the language can do, at that state. As they have time to dig in deeper, they can learn more and more of the advanced features and sue them — if they want to. But they don’t have to.

Our goal is that the same will be true for Mercury. if you know VB.NET, you can use Mercury without learning a single new (langauge*) thing. But there’ll be more for you discover , if you want to.

The best feature enhancements IMHO, are those that you don’t realize you are using (say, a limitation you might nt ever have thought about is being removed. You can suddenly call that method that returns a Pointer, when before you couldn’t, for example), or that extend an existing feature in an intuitive but additive way (such as For Each Matching & For Each With Index.

1 Like

I really like what I am reading, @mh. Let’s wait and see the end result.

I hope that, as @Theo69 promised, there will be a good balance of new additions/changes to VB.NET, because too many could lead to adverse effect.


Glad to hear! please help spreading the word, and keep giving feedback!

1 Like

bugs://84164 got closed with status fixed.