Sorry, that's not the case. I got to this code because I needed to do something, and Swift forced me to do it this way.
It seems like the semantics of the code are good in terms if producing variable names tied to appropriate closure scopes ... it's just kind of sad that there's so much right-word drift required ... imo right-word drift like this tends to imply to my mind that some blocks are conditional and/or potentially run non-sequentially -- a sequence of statements at the same indent level on the other hand makes me more confident that all the lines have a sequential execution order (with respect to time) and share the same execution optionality ...
I wonder if a feature inspired by koka's with syntax could fit into swift somehow? -- The Koka Programming Language -- A syntactic transform that allows "turning the rest of the block scope into a closure and pass that closure to another function" could maybe provide a more pleasing way to spell this style of code?
Maybe it could be restricted somehow to only be valid in contexts where sequential statements in nested closures are known to be unconditionally executed ... a kind of sugar for building nested towers of closures where all the statements in each closure are always executed exactly once and in the written order top to bottom ...
1 Like
In C# there's a new way of using using where you omit the curly brackets and whatever you're declaring with using last for the current scope, instead of creating a new one. Something like that, or what you mention would help to make this prettier.
C# also have joining (I don't know what's the word for it) of using, where, instead of
using (var c = new Client())
{
using (var d = new Request(c))
{
yourCodeHereTm(d);
}
}
you can write
using (var c = new Client())
using (var d = new Request(c))
{
yourCodeHereTm(d);
}
The problem with that approach is the chaining of the return, which one skip by passing local state to the closures and returning outside of them, but ... I'm pretty sure chaining return is faster than passing state to a closure with all the housekeeping needed and all.
Sure, there is some “syntactic sugar” like all languages, but “favouring brevity” is explicitly contradicted by the official design guidelines.
You can freely write the basically equivalent
using(Client()) {
using(Request($0)) {
yourCodeHereTm($0);
}}
if your goal is to eliminate some perceived nesting (without eliminating actual nesting, since c has to exist to initialise d). Not that using makes much sense in Swift, anyway.
I like the idea of last-statement implicit return. It's a little annoying to add a line to a single expression or break it apart for clarity and then have to add a return as well. It doesn't prevent early returns (for those that like scanning for them -). For indicating void return, I'd prefer using the underscore as the last expression instead of a semicolon since it has the "no-value" connotation , but not sure how often it would be needed. If the func return type is Void - the compiler could simply ignore the implicit return rule. Of course the _ would make it explicit for readers of the code.
I don't think that is correct: The usual meaning of the underscore is "there is a value, but I want to ignore it". There is no need to invent new spellings here, as there are at least two ways to express void return (plain return and return ()).
1 Like
This discussion is in the context of obviating the need for a return statement, (as described previously in comparison to Rust). Nothing is going to prevent you from explicitly using return if you prefer it.
I'm on the fence with regards to the idea of adding implicit returns, but I feel it worth pointing out that this would be necessary if we were to do so. Today, every Void function implicitly ignores (and the compiler enforces explicitly ignoring) non-void returns. You'd have to do continue doing so to avoid breaking vast quantities of existing code.
Even so, () is still the canonical way of expressing a void value. So a naked void as the last line should work, without the need for an underscore.
My point is that there should not need to be anything for a Void function.
There should be no need to add anything to existing code where Void functions and closures have nothing.
So we are just considering the case where people feel something should be present as a visual indicator of intent.
Adding parens just before a closing brace seems ugly and looks like a misplaced call. ()}. It’d be especially noisy with a lazy closure ()}(). Having just a semicolon seems a little too subtle to me ;} , but ok. , An underscore is intermediate and seems both clearer and more visually appealing _ }
Just my 2 cents...