static var arguments: [String]
https://developer.apple.com/documentation/swift/commandline/2294816-arguments
Why is it var and not let?
3 Likes
Interesting. I used to be a computed property:
But it's not anymore.
Your link is about NSTask-like swift class, but here I'm asking about CommandLine enum.
Actually, the second question: why is it enum and not a struct/class? Is there a specific reason for choosing enum over other variants?
Before CommandLine existed, the arguments property was on the Process type. (Walked backward in GitHub to find this.)
It’s effectively being used as a namespace here. You can’t instantiate enums.
1 Like
Sometimes frameworks parse command line arguments first and only leave the remaining ones for your app to see. For example: Gtk – 3.0
I assume that's the reason.
In CommandLine you are affecting the whole state of the process from any place of the code at any time, while in GTK you can pass a copy of the args and GTK is actually expected to filter out its contents.
Unless there is a specific reason to make this read only by its nature variable writable, I wonder if this has had been overlooked, had it not?
You don't pass GTK a copy, it gets a pointer to the originals and modifies them.
There is such way though. You can avoid changing the state of the singleton.
It's an enum because CommandLine is just being used as a namespace, so we don't want you actually instantiating any instances of it. The compiler can prove that a frozen, caseless enum is not instantiable; it can't prove that for a struct.
As for its settability, I don't know what was in the implementor's head at the time, but I'm guessing the reasoning is basically "why not?" It can be convenient to structure command-line tools as removing or rewriting parts of the argument list before later stages of the program process it, and there isn't a compelling reason to prevent that kind of design.
In any case, it would be a breaking change to make it read-only now, so I doubt it's going to change.
1 Like
I seem to be seeing a lot of issues that boil down to "namespaces." Has there been any consideration of adding the equivalent of C++ namespaces? Using a case-less enum as a namespace seems to be a recurrence of using a C++ class as a namespace "back in the day."