In VB we have ByVal and ByRef.
I’d like to see In and Out added.
Syntax:
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.
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.
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.
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 Evolution of the Oxygene Language | Oxygene | RemObjects Software.
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.