A guard is an interesting idea as it is really just saying to not perform the
function if.
Of course a lot of the cases you are guarding against is where a value is
null/nil and would have caused an abend if passing a null.
Now with options though if you have one option -> map -> new Option you
In my experience, early returns usually reduce spaghetti and it is why I’m a
huge fan of guard since it encourages this pattern. In an effort to return as
early as possible, my conditions usually coalesce into small nuggets of logic
that all terminate with a return which makes them really easy t
The difference between issuing return embedded in multiple locations to reduce
verbosity is actually slightly more than extra verbosity it is actually a
different execution path.
In my last example (Scalaish). The last and only expression in the function is
the whole match case - it terminates
Well, it’s debatable if this would be simpler considering you’d introduce a new
syntax. However I agree that inferred return type would be great.
If we can do:
var aProperty = 10
It would be nice to be able to do
var anotherProperty { foo * 2 }
— Radek
> On 21 Dec 2015, at 08:52, ilya wrote
For those simple computed var cases I wonder if we could use a simpler
definition, inferring the type:
var twiceSomething => something * 2
On the other hand, it's better to specify types for names that can be
visible outside of current scope explicitly. So may be the getter declared
via this synt
I honestly don’t have a problem with having to say `return` inside functions.
That’s not necessarily a -1, but I’m reluctant to say +1 when _even I_ don’t
really have the problem with extra verbosity.
*However*, as others pointed out, having to type `return` is a bit tiring in
the context of a
I have to agree with everything Ilya has mentioned in her response.
It comes down to readability. Omit the "return" keyword from a function and
points that the function returns become hard to see. The optional "return"
keyboard in Ruby is one of the few features of Ruby that I genuinely dislike
Also since the example rewrite is a single line function it could be rewritten
as:
def f2(input: Integer) : Integer = input match {
case _ if input > 10 => 10
case _ if input < 0 => 0
case _ => input
}
Even with the overkill of pattern matching it — it still is easy to understan
Having returns all over the place in the middle of the code already is sloppy
to my eyes, I prefer to try at all cost to avoid spaghetti like code.
The downside of Swift not having everything as a function/expression - or at
least other replacements for them is it tends to encourage spaghetti
-1 on inferred return type and omitting return with func
Both features are actually available in the language as-is, just not with
the func keyword:
let someInferredFunction = { _ in 5} // () -> Int
When teaching Swift we actually teach func + return keywords together, they
make it easy to see
Just food for thought: C# has a special syntax, inspired by its own lambda
syntax, for single-expression functions:
> // lambda syntax
> param => param + 4
>
> // single-expression method syntax
> int AddFour(int param) => param + 4;
Swift's syntax for declaring functions and lambdas are harder
I'm not going to go as far as a definitive +1, but I've definitely wanted this
for var and subscript getters. If it were limited to single-expression
functions, I don't see much harm. The only time there'd be a problem is if the
return types matched and you were going to have another statement i
Great points Kevin, that's pretty much my thinking as well. If we're
heading towards everything being an expression then it'll happen, perhaps
that change shouldn't be incremental as you've suggested, I'm not sure.
The only time I've found I've naturally wanted to do this is with things
like prope
If Swift ever changes to be Rust-like and have every statement actually be an
expression with a non-void type (I believe this was discussed in the thread
about replacing ?:), then your proposed behavior is already an implicit part of
that change.
But barring a large change like that, I'm agains
In this scenario, should calling a warn_unused_result function as the last
statement in a closure/function count as "using" its result (i.e.
implicitly returning it)?
Jacob
On Sat, Dec 19, 2015 at 4:51 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:
> Is there a reason th
I looked at the discussion and it looked like they were discussion two things
combined.
- inferred return type (on function signature)
- and omitting return on the return.
I agree with Chris on the fact that the function should have the type of return
specified on the signature and not in
-1 for me. Closures gain a special syntax because of their use case,
specifically inlining locally. Functions don’t get that.
> On Dec 19, 2015, at 4:44 PM, Andrew Bennett via swift-evolution
> wrote:
>
> +1 for consistency with closures
>
> On Sun, Dec 20, 2015 at 8:15 AM, Stephen Christophe
Is there a reason that any final non-void statement in a closure or function
shouldn't automagically be an optional return? (And automagically
warn_unused_result...?)
> On Dec 19, 2015, at 5:44 PM, Andrew Bennett via swift-evolution
> wrote:
>
> +1 for consistency with closures
>
> On Sun, D
+1 for consistency with closures
On Sun, Dec 20, 2015 at 8:15 AM, Stephen Christopher via swift-evolution <
swift-evolution@swift.org> wrote:
> The discussion I was remembering, comment courtesy of Chris:
> https://devforums.apple.com/message/1014317#1014317
>
> (linked from https://devforums.app
The discussion I was remembering, comment courtesy of Chris:
https://devforums.apple.com/message/1014317#1014317
(linked from https://devforums.apple.com/thread/255242)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/ma
Yes, this would be strange in multiline functions with different execution
paths. It works well in Ruby because function return types aren't
annotated, so the final expression is always a valid return value. In
swift, I think it would have too much design overhead to figure out how to
reconcile it
There was discussion of implicit returns on the forums a while back. Will try
to find the link later. The Swift team chose explicit returns for better code
clarity. I still think this was the right call, even though implicit returns
are certainly attractive when writing code.
> On Dec 19, 201
Afaik the concept is quite common when "everything is an expression", which can
be a nice feature of a language:
It saves keystrokes, and allows constructs like
let value = switch key {…}
But as the let syntax was changed to work with delayed assignment, one major
use case is solved in a differen
Not sure if I like this or not, but if we do adopt it I think it should be
consistent with the rule for closures. Following the current rule for
closures, this would only apply to single expression functions. I think I
could support that.
> On Dec 19, 2015, at 9:53 AM, Dennis Lysenko via s
This is very nice for writing lazy var definitions and single-line computed
properties as well. +1 from me.
On Sat, Dec 19, 2015, 8:30 AM Craig Cruden via swift-evolution <
swift-evolution@swift.org> wrote:
>
> When writing short functional code in a function it would be nice if the
> return keyw
+1
On Sat, Dec 19, 2015 at 2:30 PM, Craig Cruden via swift-evolution <
swift-evolution@swift.org> wrote:
>
> When writing short functional code in a function it would be nice if the
> return keyword were an optional keyword.
>
> Just return the last evaluated expression.
>
>
> i.e.
>
> func f
When writing short functional code in a function it would be nice if the return
keyword were an optional keyword.
Just return the last evaluated expression.
i.e.
func flipFunc(arg1: T, arg2: U) -> (U, T) {
(arg2, arg1)
}
The keyword return would still be there for breaking
27 matches
Mail list logo
