In some problems spaces those chains + iterations arise naturally (this is why I gave an application of an external library as an example, which is not perfect for such a pitch, but this is a real application and not theoretically constructed examples). So there is nothing confusing about it – on the contrary, having to resort to break those chains with a lot of if let is more confusing in those cases. I would regard it as a tool that sometimes matches quite well the problem space.
Am I missing something or is it indeed a good solution which allows the
for x in y ?? .empty
syntax out of the box without a compiler change?
Re: the new trailing question mark syntax. How would it look like with "try?". This?
for x in (try? foo(param: 42))? {
...
}
IMHO this one is better (even if slightly longer):
for x in try? foo(param: 42) ?? .empty {
...
}
That‘s an opinion. As I already explained, I do not think so. To much ornament, and very repeatedly if you “iterate” a lot through of those optional chains.
(It is also not really what you want to express: You want “do not iterate if there is nothing to iterate through” and not “if there is nothing to iterate through, then please iterate through something empty”.)
And I would not jump on the easiest solution, a compiler change is a good thing (in the long run) if the according solution is the preferred one.
No, should be simpler (added a remark in the pitch draft):
for x in try? foo(param: 42) {
...
}
1 Like
Hmm, if foo is
func foo(param: Int) throws -> Int
then y's type:
let y = try? foo(param: 42)
is inferred as Int? and I would expect the same to happen within
for x in try? foo(param: 42)
expression, meaning that you either allow arbitrary optionals to be treated this way:
var y: Int?
for x in y {
...
}
or you are changing the language semantics to treat "try? foo" differently depending upon whether it is in the "for in" or not, which is a surprising behaviour.
This would be of course a special rule in the sense of “if an appropriate question mark occurs, this should suffice to make clear that we are dealing with something optional” (as already discussed elsewhere), and this of course is not a must-have of the proposed solution and maybe a separate topic. I would accept the more complicated for x in (try? foo(param: 42))? if this is seen as a problem.
I believe such special treatment would be a problem, and indeed you'd need to reach out for this parenthesised syntax, and this too me indicates a problem: the postfix question mark bounds too tightly (has too high precedence). Ditto could be said about the .orEmpty.
Could you clarify on this, with an example perhaps. I could only imagine that the thing we are talking about being used once in the expression, not repeatedly, but maybe I am missing something.
When you want to iterate through certain things if they are there, and else do not care, and do this in many cases, you end up with having to add “ … ?? .empty” many times if using for-in loops, repeatedly. I have those cases when working with XML — you see one example (i.e. one case) in the pitch draft. Imagine many similar cases. Real code that I could give you would be closed source under an NDA, so I hope you can imagine that there might be some more variants of the example given in the pitch draft (all in one application or even in one source file).
Also see the citation from the old draft in the Motivation section where some other possible application are mentioned.
Update: It is not about writing one smart, compact algorithm, but code that processes complex data and needs a lot of those loops.
You could also have a multitude of foo ?? bar unrelated to for in loops. Do you simply not like the aesthetics of it?
foo ?? bar in the general case expresses something different (bar being something you might really be interested in as a value and not just an empty thing as a means to actually doing nothing) and I do not see how it could be shorter.
1 Like
Update:
This pitch (which was started by me) seems to be in hibernation again. It has been discussed and I tried to consider the discussion in the pitch draft and also give more convincing (or “refined”) arguments. There have not been new comments for some time now.
An implementation (which, according to the proposal, would need changes in the compiler) is still missing, and I will not be able to add an implementation myself.
I do not know if any further discussion in this thread would help, as I think many arguments have been presented. If you like to discuss the topic further, then maybe a new thread should be startet as maybe not all commenters are still interested in the topic.
I also mentioned that maybe a rewrite by another person could be helpful if anyone thinks that the proposal presents a welcome change and this person has a good idea how to present it in a more convincing way.
Thanks to everyone for the discussion.
Sorry to not be of much help on this, from where I am:
- I'd slightly prefer
"for x in foo() ?? .empty"which could be implemented without compiler support and especially because??has a lower precedence compared to the mentioned alternatives (which lower precedence is a desired property in this case as it avoids unnecessary brackets, e.g. when used with try?). - Regardless of whether it is in the
"for x in foo()?"form or in the"for x in foo().orEmpty"form or in the"for x in foo() ?? .empty"form I'd use it if it was available in the standard library. - Until it is available in the standard library I'd probably not bother implementing it in my personal library for my own consumption, as it doesn't look a big win for me.
Anyways, good luck with your pitch.
You certainly mean it well, but nevertheless your wish sounds a bit strange to me as I just explained (in a diplomatic way) that there is nothing more I can do for this pitch. More explicit: Without others joining or taking over, I guess this pitch is dead.
Also, I really tried to consider your arguments in the pitch draft, so I think your last repetition was kind of unnecessary. But OK…
@ all: Please read my last comment above as a kind of current conclusion.