Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

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

Re: [swift-evolution] Remove forEach?

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

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

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,

Re: [swift-evolution] [Proposal] function "return" optional keyword.

-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

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> 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

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

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?*

Re: [swift-evolution] [Proposal] Type Narrowing

> 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

Re: [swift-evolution] [Proposal] Type Narrowing

> 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

Re: [swift-evolution] [Proposal] Type Narrowing

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

Re: [swift-evolution] guard let x = x

> 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

Re: [swift-evolution] guard let x = x

-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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

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