It has been [0] days since I used 'return' inside a closure attempting to exit from the surrounding function.

Related: What’s the least horrible syntax in Swift for returning from the surrounding function inside a nonescaping closure? The closure doesn’t loop, but has a generic return value you can use (it’s void right now).

(Think NSLock.withLock {} and the like)

#swiftlang #programming

@uliwitness uh, like an error? What you describe just sounds like a construct that shouldn’t exist.

@jongary @uliwitness yeah apart from throwing to unwind 2+ stack frames, or goto, what would that be?

Ruby does this, and it confuses the hell out off me :)

I hope break to a label doesn't work here bjt maybe it does?

@ctietze i can only think of exceptions, but I don’t think that was the situation described.
@uliwitness no goto/longjmp?
🤪
@DerPumu Don't tempt me. I grew up on C++ class libraries without exceptions, and which still had the 'inherited' keyword 😅
@uliwitness that must have been a "special flavor" since that never was a keyword in the language. C++ without exceptions is relatively common when you deal with smaller embedded devices. But both goto and longjmp are largely incompatible with C++ object lifetimes, so that should be C 🤭

@DerPumu I encountered that in CodeWarrior sometime between 1996 and 1998 I think ...? I thought it was part of C++. Could have been a leftover from C with Classes maybe? Or pre-ANSI C++ ? I'll have to browse through Design and Evolution again, I suppose?

It probably predates support for multiple inheritance. You wrote

void Subclass::Foo() {
inherited::Foo();
}

instead of

void Subclass::Foo() {
Baseclass::Foo();
}

@uliwitness I'll have a look at D&E I guess, but it definitely never was in the standard
@DerPumu I guess if it's mentioned at all, probably in whatever chapter covers (multiple) inheritance.

@DerPumu Found it!

Design & Evolution of C++, 13.6 Inherited::

Apparently it was a proposal that got implemented by a few compilers and was almost accepted until they decided it wasn't really needed.

@DerPumu The longjmp approach was in several languages. I think it was TCL (THINK Class Library) that used it, but yeah, other C-based languages used it too, like Objective-C. And yes, it of course causes problems for C++ because you *must* catch at every level for destructors to be properly called on error.

Objective-C autorelease pools of course get cleaned up either way, so wasn't a problem for that language.