My first point was to get clear that the two proposal solve different issues. Thus, there is no need to choose one or another. As I see it, discussing if we want [guard self] is independent of the guard let self = self else { ... } proposal. Can we agree on that?
About the rest:
In case guard let self = self else { ... } is confirmed, you are right about the consistency argument.
If you want to halt execution with fatalError(), then you do not use [guard self]. As explained, [guard self] is syntactic sugar for a very concrete scenario, where you dont want to execute the code in the closure if any of the identifiers in the capture list is nil. And despite being a very concrete case, in my opinion the [guard self] proposal makes sense due to the high amount of times this pattern appears on the code.
I understand. As I see it, this toggle() proposal that was recently accepted is adding syntactic sugar that is really useful only in a very concrete case: when in larger nested structs. If you are not in an scenario with a large nested struct, then the advantage for using it is not so much.
If such a proposal was accepted, I wonder why not this syntactic sugar proposal that is being discussed and requested during years would not be accepted, or at least seriously considered as a proposal.
I think the acceptance and rationale of the toggle() proposal is a good starting point for, at least, making an official [guard self] proposal, and end up the recurring discussions about it.
Yes, this topic is very old, but even after discussing it a lot, I have been reading all the information I could find about it and the result is:
a) This was never oficially proposed in swift evolution.
b) I could not find a proper rationale of why there has never been an official proposal, or why this syntactic sugar is undesired. Seems to me that when the discussion was happening, it was not the right time for this, or the people supporting the discussion gave up.
c) Because there has never been an official proposal, there is no official rationale from the core team for or against it.
d) From the discussion and the comments in here, seems to me that there is still interest on this, or alternatively, on a solution for the capturing weakly and then unwrapping commonly repeated scenario.
I see your point. Maybe guard is not the right keyword for this. It seems to me the right one, but of course having a similar implementation with another keyword that fits better is an alternative.
Well, I think what less experiences engineers do is not use the capture list, thus creating reference cycles. And, at the moment they realise that when using closures almost everything should be captured weakly and then unwrapped, is when you start wondering: is there any alternative for this commonly repeated code [weak self] in guard let strongSelf = self else { return }?
Also, if you are using [guard self] you should be aware of what you are doing. Using the features of a language without even reading what they are intended for is a bad habit. Using features of a language that allow you to write clearer, more readable code, I think is a good habit.