I'm unconvinced. We already have the perfectly functional "unwrap or die"
operator, that is, the *force unwrap* *! *operator.
Can it be improved? Definitely. If the developer wants to provide some
context for a possible fatal error, it would be great for the language to
give the tools to express i
I'm not sure those examples are what we should aim for. Generally I try to
avoid force unwrapping, and specifically in these cases I belive a more
reliable code would be produced without either ! or the !! operators:
https://gist.github.com/ilyannn/4c5530c75293db0324a04f50ae691b2a
I understand co
Hello to all of the community.
** What is your evaluation of the proposal?*
+0.5
Agree on the motivation and 'public open class'
Let's discuss 'public open func' + application to dynamic runtime
** Is the problem being addressed significant enough to warrant a
change to Swift?*
*
> limiting “open” to public classes only lets you be sloppy inside your
own module.
I don't find that idea bad actually.
In the similar vein one can say "it's ok to be sloppy with local variable
names, it's not ok to be sloppy with instance variable names".
Again, tradeoffs. You can require tha
-1 on
if unwrap myValue { ... }
In my opinion, *shadowing names is an anti-pattern,* so making it easier
isn't something we should encourage. Detailed examples, shall you wish, are
below.
Consider a developer who is suddenly able to change all employment
relationships in the company.
He's happi
> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }
I would argue for
c) guard let reallyFoobar = foobar else { … }
(or perhaps guard let foobar_ = foobar else { … } )
That way one can use both an optional foobar and non-optional "unwrapped
value of foobar at the moment
If I correctly understand the proposal, I'm -1 on this.
(1) You can define different methods with the same name on T and
Optional (description is such an example). Then what does this do?
// someMethod is defined both for T and T?
// var foo: T?
if foo != nil {
foo.someMethod()
}
I say there
> What do you imagine being inside .complicatedStuff()? It shouldn't be
possible for it to change foo to nil, as even if .complicatedStuff()
reassigned this, it would be doing so as type T.
Why do you think so? All objects can be changed in any method. Let's rename
foo to pet and complicatedStuff
> The difference here is that unlike shadowing (if let foo = foo), if foo
were mutable then it could still be mutated directly, no need to do it with
force unwrapping.
FWIW, there is no need for force unwrapping in any case.
var bar:Foo? = nil
if let real_foo = foo {
bar = real_foo
}
if var bar
I prefer
if let vc = someInterestingViewConroller {
vc.doSomething()
}
- Explicit is better than implicit
- shadowing is bad
- now there's no ambiguity about how to change the original property.
Therefore I'm -1 on any proposal that hides explicit name binding and/or
increases shadowing, includi
-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
> If we don’t change the default maybe we should at least add a warning
when you *could* add @noescape but didn’t. A lot of folks are likely to
leave it off when they should really be adding it.
I like this idea. We have a warning for variables that can be made into
let, so why not this?
On Sun,
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 like having separate forEach. As already said, forEach produces different
visual grouping of logic compared to for operator. It's especially useful
if you just pass a named function to it.
forEach is also not the same as map:
let block: Int -> Void = ...
[1,2,3].map(block)
Here the result has
Honest question, where's the guarantee that the optimizer isn't allowed to
optimize defer {val} away?
On Thu, Dec 31, 2015 at 00:33 Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Dec 30, 2015, at 1:27 PM, Kevin Ballard wrote:
>
> On Wed, Dec 30, 2015, at 09:53 AM, Joe G
15 matches
Mail list logo