[swift-evolution] Inconsistencies related to prepositions

When Swift 3 launched, it introduced a new concept of placing the preposition inside the parentheses. (See discussion here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009523.html). I'm fine with that, however this change got implemented in an inconsistent manner,

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Ethan- This is brilliant. I don’t know if it’s technically feasible, but this is how it *should be.* - Jonathan > On Oct 2, 2017, at 17:28, Ethan Tira-Thompson via swift-evolution > wrote: > > I’m all for fixing pressing issues requested by Xiaodi, but beyond that

Re: [swift-evolution] [Pitch] Improving KeyPath

I concur with Logan’s idea here on the general points, but let me add a bit more. Here are some KeyPathy things I’d like to see in a future Swift: /// A set of PartialKeyPath guaranteed as: /// (a) the entire set of keypaths for a type; and /// (b) accessible given the current scope

Re: [swift-evolution] continuations - "extensions on steroids" idea

I like the ledger list idea better than saying “this class is partial” and now it can be extended anywhere. Adam said below that, “you have to trust your fellow developers,” but that’s BS. You can’t merge a PR to master without approval, and some repos you have to PR from a fork. It’s easy

Re: [swift-evolution] continuations - "extensions on steroids" idea

On Nov 3, 2017, at 14:36, Adam Kemp via swift-evolution wrote: > > If you work with people who can’t follow conventions and would try to extend > partial classes from random places then I’m sorry. :) This seems naive. Swift is based on the idea of making it

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

-evolution >> <swift-evolution@swift.org> wrote: >> >> Colocation of docs with the material they document is valuable to me and I >> presume anyone updating code. If anything, it would be nice if Xcode >> provided a show/hide doc headers toggle though. >&

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

They removed the little UI sidebar that was so useful for code folding, though. I do hope it makes a return. Also I am not saying projects should be forced to keep docs in separate files, just that it would be nice to have the option. I suppose it could be achieved through an XCode plugin

[swift-evolution] [Pitch] .swiftDoc files instead of inline docs

When I go to look at the actual source code of something, it’s almost always because: (a) the documentation was insufficient for me to really understand what’s going on, or (b) I already know what’s happening but I just want set a breakpoint for debugging. In both of these cases, the presence

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution > wrote: > > Personally, I feel this system is designed to let you write Python, using > Swift as a wrapper language - except unlike with Objective-C, Let me paraphrase the proposal—it basically says this

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution wrote: > > So the use case here is, how do we make Swift a viable candidate for doing > those things which today drive users to Python? The answer here is _not_: > build a better Python. Nor does it require,

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

See below. > On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution > wrote: > > Apologies, I may have misunderstood you. What I wanted to say is that I see > no problem allowing "dangerous" stuff that may be abused. You see no problem with danger and abuse? I

Re: [swift-evolution] Making capturing semantics of local

I have run into nondescript compiler crashes (like segmentation faults, etc.) when using local functions to do certain things, like wrapping the parent function’s escaping closure arguments in other closures that capture variables from the parent function’s local scope, especially when those

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Having reviewed much of the commentary on this proposal, I keep coming back to the same thought: why not use @versioned and @available keywords for this instead of some concept related to “exhaustive”? The issue here is not whether a given enum is “exhaustive” over the enumerated problem

Re: [swift-evolution] [Pitch] Percentage Type

No to this pitch, because a percentage can be higher than 100%. Use NumberFormatter to display a number as a percentage. https://developer.apple.com/documentation/foundation/numberformatter Or you could make an NSNumber subclass if you want to enforce an arbitrary rule upon numbers. Jonathan

Re: [swift-evolution] namespacing protocols to other types

Amen. This seems like an appropriate step towards better name-spacing, and it’s one we have sorely missed on one manor project at work. We maintain a framework that wraps our various web APIs with convenience methods and data model types. Since the APIs are versioned, we have nested most