Re: [swift-evolution] Better syntax for deferred?

Deferring at the end of the function removes the ability to defer actions on variables introduced in an inner scope. On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > I have the terrible feeling something is wrong with my posts so that they > get

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

Everyone, The sticking point here is that xcode generates the first syntax automatically. Simply filing a radar about this would be useless, so I believe the original proposal is meant to sort-of "light a fire" under the Xcode team; by introducing a new language feature they would be forced to

Re: [swift-evolution] Failable Initializer Suggestion

My initial stance several months ago was that initializers should throw instead of returning nil, but I've changed it as a result of the error handling rationale (same document as Chris linked). Specifically this section, taken from ErrorHandlingRationale.rst: Simple domain errors A simple

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

it seems nonsensical. Perhaps this would > be closer to Swift’s goals, by reducing very common boilerplate, but > without harming clarity in a way adding a new meaning to “let” would. > > Curious to hear Chris Lattner’s opinion :-) > > > IANACL (I am not a Chris Lattner) but, F

Re: [swift-evolution] [swift-dev] Scala updated equivalent

+1. This is very functional. Need to drill home the point that arrays have copy semantics in the intro swift docs though, if we start going in this direction. On Tue, Dec 22, 2015, 7:12 AM Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > Moving to swift-evolution. > > On

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

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

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

What if we made the keyword "unwrap"? if unwrap someViewController { // now there is a shadowing nonoptional (unwrapped) variable of the same name only within this scope, boiling down to simple syntactic sugar for optional binding and it is fairly clear. } On Sat, Dec 19, 2015, 1:31 PM Kevin

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

Disagree. Short names are less descriptive and less readable. And saying "shadowing is bad" without any argument is just silly for a mailing list. On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 19, 2015, at 12:37 PM, ilya via

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Genuinely, David, thank you for taking up the mantle of this problem. To me, the lack of type annotations makes the error handling painful and I wish the team just hadn't released it until the design was smoothed out fully. Those dangling catch-all blocks when I've caught all cases make it

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

Felix, This seems to be very interestingly tied into your comments about polymorphism in 'throws' type annotations. Would you not feel that allowing enums to be built on top of other enums would promote the kind of egregious proliferation of exception polymorphism that discourages so many from

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Sorry Matthew, I think my email is having delivery issues because I didn't see any of those messages when I sent mine, though I see them timestamped before my message now. Yes, Felix, those were valid concerns. But, as mentioned before, what we have now is the most polymorphic thing possible. All

Re: [swift-evolution] ternary operator ?: suggestion

+1 to Jordan's points as well. Generally speaking, there is clearly a wide variety of things that cause people to be interested in this particular proposal and I don't think we can reconcile all of them. For example, I think that "collapsing an if statement into one line" isn't a good enough

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

Charles, While I agree it's unfortunate that there isn't much interop between ErrorType and NSError, the decision from the core team to make ErrorType an empty protocol seems to have been a premeditated one. I would love to have someone on the core team respond here in my stead, but I'll try and

Re: [swift-evolution] Brace syntax

Also, Ruby has braces, though it is generally stylistically suggested to only use them for inline blocks (arr.map { |x| x.name.chars.first }) and when you don't use braces, you use even more verbose `do`/`end` syntax. I don't know many people who have experienced a large variety (8+?) of

Re: [swift-evolution] Final by default for classes and methods

Actually, Curt, not that I'm in favor of this proposal, but you inspired an interesting thought--I think that if extensions were more powerful (e.g. stored properties), then having closed classes by default might not be such a big deal. What's the difference between using a `MyViewController`

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

Sorry, got a little excited in answering and just re-read the proposal. Ignore the part of "extra cruft", since I'll never have to see it unless I want to override it. I thought that the static dispatch bit later on in the proposal implies that that wouldn't work so well, but I might have misread.

Re: [swift-evolution] Proposal: Python's indexing and slicing

Dave, perhaps we could use "^" as an anchor point for the start index and $ as the anchor point for the end index? It's familiar to anyone who knows a bit of regex, and all vim users. My main worry would be ^ is already infix xor operator. On Fri, Dec 18, 2015 at 5:43 PM Paul Ossenbruggen via

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

FWIW, I rely on typing `tableView` and looking at the autocompletions to find delegate methods. Not that that makes this a bad idea, and I'm not sure how many other developers do that (although I imagine quite a few do). Just food for thought. On Mon, Jun 27, 2016 at 11:44 AM Saagar Jha via

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

My 2c: This proposal is made more appealing to me because it is not simply a 'beginners will get confused' issue. I have written tens of thousands of lines of Swift from Swift 1 to the Swift 3 preview and I still can't shake occasionally accidentally capturing `self` strongly when I, for

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!. The limited scope of this proposal is ideal in my opinion since we see areas

Re: [swift-evolution] Guaranteed closure execution

Just curious, is there a deeper-than-semantic difference between a @noescape(once) closure and an inlined closure? On Sun, Apr 24, 2016, 5:58 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution < >

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Oops, completely missed about 57 messages in the meat of this discussion, so apologies if what I said was already suggested. On Sun, Sep 25, 2016 at 4:35 AM Dennis Lysenko wrote: > Could take a page out of Kotlin's book: > > x.let { foo(it) } // default argument name

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Could take a page out of Kotlin's book: x.let { foo(it) } // default argument name that isn't $0 IMO, this syntax looks better as a one liner than "if x? { foo(x) }". The edge case here, with foo and bar being optional-returning functions, becomes: (foo(42), bar(43)).let { x, y in foo(x, y) }

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

So a lot of concerns here especially ilya's are ones that wouldn't be brought up if people looked at existing successful implementations like Kotlin where they are clearly solved. (fyi, answer is only narrowing with immutable values.) Personally I think type narrowing with explicit opt-in has no

Re: [swift-evolution] Some clarity lost from the great renaming

I think if it's one example like in this instance then a compiler directive to specify mapping if one does not already exist would be a more prudent option than changing the entire mapping. On Tue, Oct 18, 2016 at 9:51 PM Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > Is

Re: [swift-evolution] Some clarity lost from the great renaming

Agree on this particular case being unintuitive. I've come across a number of such cases in Swift 3 but never really put too much thought into them. Maybe you could just use for: UIControlState.normal until a resolution for this is found (if there is one). On Tue, Oct 18, 2016 at 10:32 PM Dennis

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

That's a good point in Jay's example and from what I can tell a good way to address it, Haravikk. I've done some work in a language that only provides type narrowing for immutable types (that'd be Kotlin as I've mentioned before) and whenever I've used it it feels like the only thing it's really

Re: [swift-evolution] Swift Extensions on Overlay Structs

Hmm... would it be possible to define a protocol like "UnifiedURLType", define each of the properties you need to work with inside your extension functions as protocol properties inside the protocol UnifiedURLType {} declaration, create an extension UnifiedURLType {} and include doSomething()

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

assessment, which is why I'm a little hesitant on the proposal, but as I've described before I think it would help expressiveness. On Sun, Nov 13, 2016 at 11:16 AM Jean-Daniel <d...@xenonium.com> wrote: > Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution < > swift-evolution@swi

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

FYI, the emoji bar with ctrl cmd space has worked that way since at the very least El capitán, and I think as far back as mavericks. Le lun. 31 oct. 2016 11:59, Haravikk via swift-evolution < swift-evolution@swift.org> a écrit : > On 31 Oct 2016, at 10:14, Alex Blewitt wrote:

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

Gonna put in my 2 cents re shadowing being a source of bugs: I use explicit self everywhere in my codebase and it pairs wonderfully with shadowing, making the detailed example moot. As far as Dany's message, I think that's the best way to go forward with an unwrap keyword--just make it work