Is there a way to "replicate" this feature found in other languages?

Not sure why, though ¯\_(ツ)_/¯

I think when Swift gets a full-fledged ownership model, it would enable treating inout as a declaration modifier, rather than specifically a parameter modifier. I can image future being able to have inout return values and local variables being inout as well, which would cause Swift to track the lifetime of the reference that is passed around as inout and do necessary heap-allocation to make sure the referred storage stays alive (much like closure-captured variables).

Most programmers haven't worked with Visual Basic, so I don't think it's a good idea to write visual-basic-looking-code in Swift.

Even if the myRoutine("foo")="bar" syntax were possible to achieve, it wouldn't make sense to any Swift devs.

The Swift syntax for reading and writing values into an object, with some location specified by parameters, are subscripts. I would suggest you use that.

2 Likes

This is not a true statement in my opinion. And the entire basis of this project is to be able to provide an alternative developement envirionement to an existing base of developers. The fact that the output is Swift code is really transparent to the developer audience this is intended for. So since the feature being discussed here is available in that language is the reason I need to support it here.

The 2nd solution posted above by @sveinhal seems to work.. .although I thought that declaring a variable inside an Extension was not allowed... but anyway, I tested it, and it works. Thanks

It is not possible to declare a stored variable in an extension, computed (getter/setter) variables are allowed.

1 Like

Its too early :slight_smile: I failed to notice that distinction...
Thanks

In that case, it shouldn't matter that the output looks like myRoutine["foo"] = "bar" instead of myRoutine("foo") = "bar", no?

Is this a codegen tool, whose output isn't meant to be read/modified directly?

Others have mentioned that a subscript allows this. I'm a bit curious though what that syntax buys you that a more common construct like a setMyRoutine(_ somevar: String, to new_value: String) wouldn't do, and more clearly?

Sure, you have to call it as setMyRoutine("foo", to: "bar"), but why are we forcing an assignment operator here?

1 Like

It is a matter of being able to support the INPUT syntax, and the easiest way to do that is to have a Swift equivalent.

And yes this is in fact a CodeGen tool. So I need to be able to leverage Swift to support the syntax and features of the parent language, which isn't Swift, and has a few features (such as this one) that Swift doesn't support directly.

You are all thinking purely from a Swift Point of view, and what a Swift Developer would do, where for this project I need to think for the POV of the parent language, and what that developer would do, and how I can translate that to Swift so that Xcode can compile it.

Will my translator be able to do EVERYTHING that Swift can do? Of course not, and that isn't the goal. The goal is to be able to do Everything the Parent Language can do (and fix issues and shortcomings that are known to exist there already)

So you're trying to use Swift to implement arbitrary Domain Specific Languages? I don't think that has been within the scope of Swift so far, so I think you're sadly out of luck.

What one would usually do is write a transpiler here. Create a program that reads the source text file, builds a tree structure of the program, and then recursively walks that tree to print out equivalent Swift code as a new text file.

Since your transpiler actually mostly "understands" the structure of the program, it is irrelevant what the equivalent syntax looks like and what characters it uses. It can detect that a certain sub-tree of nodes in your tree constitutes an assignment to a function, and replace it with a node that turns it into a regular function call, or a subscript, or whatever other construct feels like it would be the idiomatic equivalent to what you're trying to do in Swift.