Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Revised Dependency Resolution

Sounds familiar… https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029034.html …so obviously I’m all for it! P > On Apr 26, 2017, at 7:25 PM, Rick Ballard via swift-build-dev > wrote: > > Hi all, > > We have a proposal we'd like feedback on to revise how Swift Pac

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

I like the spirit of the proposal. It leaves me a bit uneasy because the practical ramifications are difficult to fully anticipate. Here follow some questions / concerns for the proposal authors. (Apologies if these were answered somewhere deep in a discussion thread; it’s the end of the semest

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

observed that it takes some effort to > actually get an access to be non-instantaneous. *smirk* Cheers, P > On May 3, 2017, at 10:43 AM, John McCall wrote: > >> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wro

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > >> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Concern: `swap` is quoted a lot for a method that would break und

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

> On May 7, 2017, at 6:01 AM, Jean-Daniel wrote: > >> >> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> >>> On May 6, 2017, at 12:36 PM, John McCall via swift-evol

Re: [swift-evolution] Revisiting SE-0110

To add more real-world project data to this discussion, I just did a test migration of Siesta to Swift 4 using the 2017-05-30 snapshot. Nothing earth-shattering follows — just more practical evidence that the problem needs attention. Here’s what I found: (1) The lack of tuple destructing under

Re: [swift-evolution] Revisiting SE-0110

> One way to split the difference here is to eliminate the splatting behavior, > but keep the destructuring (irrefutable pattern matching) behavior as well. A hearty +1 to this, regardless of the choice of syntax. P > On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution > wrote: >

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

It should be possible to achieve Ruby-like generality in Swift with a protocol for “thing that can converted to a transform function.” That wouldn’t need a special & operator. Here’s a sketch. This sketch doesn’t compile — maybe not enough of Swift 4 is there yet for it to work, or maybe I am m

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

ote: > > this work, > > prefix operator * > > prefix func *(keyPath: KeyPath) -> (Root) -> Value { > return { $0[keyPath: keyPath] } > } > > ["Hello, World"].map(*\String.count) // [12] > > > 2017-06-08 12:19 GMT+08:00 Paul Cantre

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

Being able to specify things about closure capturing at the API level could do wonders for Siesta — though its problems may be beyond the scope of what’s proposed here (or what’s workable at all). Siesta exposes this API call: someResource.addObserver(owner: self) { // (1) [weak se

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution > wrote: > >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >> wrote: >> >> I think having a queue to submit "proposals for eventually", written when >> the inspiration is there, and having a core team review (sa

Re: [swift-evolution] Swift phases and mis-timed proposals

language bloat. That’s probably the best we can do for the concerns raised by 110 for now; I do not mean to derail or denegrate that debate. My argument is that there may be an underlying process problem — and thus process solution — to consider for future work. Cheers, P > > Regard

Re: [swift-evolution] Swift phases and mis-timed proposals

I support everything Jon wrote. +1 Free-for-all brainstorming venue separate from focused proposal discussion. +1 Working groups when helpful. +1 Longer public incubation for unstable / experimental features (but that idea executed & communicated with caution, preferably with active support fro

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 7:12 PM, Ted Kremenek wrote: > > >> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >> >> >>> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution >>> wrote: >>> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution wrote: I

Re: [swift-evolution] Revisiting SE-0110

What’s the status of this Chris’s double parens idea below? It garnered some positive responses, but the discussion seems to have fizzled out. Is there something needed to help nudge this along? What’s the likelihood of getting this fixed before Swift 4 goes live, and the great wave of readabil

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution > wrote: > > >> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swif

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution > wrote: > > > On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > wrote: > On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Thu, Jun 15, 2017 at

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 16, 2017, at 8:44 AM, David Hart > > wrote: >> >> Okay, I undertand. I’m just worried that the proposal is a net negative if >> the keywords sta

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 2:26 PM, Xiaodi Wu wrote: > > On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 3:43 PM, Mark Lacey wrote: > > >> On Jun 16, 2017, at 1:21 PM, Mark Lacey > <mailto:mark.la...@apple.com>> wrote: >> >>> >>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >>> mailto:swift-

Re: [swift-evolution] Revisiting SE-0110

> wrote: >>> >>> >>>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >>> <mailto:mark.la...@apple.com>> wrote: >>>> >>>>> >>>>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >>>>>

Re: [swift-evolution] Revisiting SE-0110

e: >> >> >>> On Jun 16, 2017, at 2:09 PM, Paul Cantrell >> <mailto:cantr...@pobox.com>> wrote: >>> >>>> >>>> On Jun 16, 2017, at 3:43 PM, Mark Lacey >>> <mailto:mark.la...@apple.com>> wrote: >>>> >>>&g

Re: [swift-evolution] Revisiting SE-0110

>>>>> On Jun 16, 2017, at 3:43 PM, Mark Lacey >>>> <mailto:mark.la...@apple.com>> wrote: >>>>> >>>>> >>>>>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >>>>> <mailto:mark.la...@apple.com>>

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

> it gives me the creeps to leave something like ‘fatalError’ in a shipping > application Agreed, and I would use it for _exactly_ this reason. I avoid force unwrapping in production code, looking first for ways to gracefully handle the situation. Whenever I do use !, there is careful reasoni

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

> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > I would like to see an example where this string plausibly makes the > difference between having to hunt down the code and not have to do so. I do > not believe that "array must not be

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

> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu wrote: > > On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell > wrote: > >> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I would like to see an example wher

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

> On Jun 28, 2017, at 10:49 PM, Xiaodi Wu wrote: > > On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell > wrote: > >> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu > > wrote: >> >> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell >

Re: [swift-evolution] Swift 5: start your engines

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but… I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Returning to the list after a brutally busy spring, a demi-review: I vote… +1 on addressing this problem, +1 on the proposal’s structural approach (list of items which may be either boolean tests or bindings, in any order), and +1 on eliminating “where” in the presence of a better approach, …bu

Re: [swift-evolution] Working with enums by name

> On May 31, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> | enum Planet : Int { >> | case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune >> | >> | init?(caseName name : String) { > > The compiler actually does this already through RawRep

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

about this. > > I am prepared to go as far as disallowing: > > let x = optionalX, y = optionalY > > syntax to free up comma for use instead of semicolon. Then the above becomes: > > let x = optionalX, let y = optionalY > > In this case we will keep the comma at t

Re: [swift-evolution] Working with enums by name

IIRC, string interpolation prepends the module name if the enum belongs to a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of compiler crashes, at least in the past. Those two factors forced me into this ugliness: https://github.com/bustoutsolutions/siesta/blob/master/Sou

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution > wrote: > > One thing I did often in Java (and miss in Swift) is using their enums to > build state machines or implement command patterns for common commands. > > Java enums are a sealed set of subclasses of the enum base type wi

Re: [swift-evolution] Working with enums by name

suggestions?) will prevent > that changes to this behaviour crash apps in the future as this should > always produce the same result even if the string representation > changes. > > L > > On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution > wrote: >> II

Re: [swift-evolution] Working with enums by name

> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This is the

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 7:09 AM, Charlie Monroe via swift-evolution > wrote: > >> We already have the concept of prefixing a type name with a module to >> disambiguate when two modules have the same type. I wonder if we could do >> the same thing to disambiguate between conflicting extensions? >>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution > wrote: > > On Jun 7, 2016, at 4:53 PM, Tony Allevato > wrote: > >> I like the "from" keyword the best, but I'll take my own stab at a >> modification: >> >> import ModuleA >> import Module

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution > wrote: > >> >> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Jun 7, 2016, at 4:53 PM, Tony Allevato > <

Re: [swift-evolution] extend trailing closure rule

> On Jun 8, 2016, at 3:46 PM, Jordan Rose via swift-evolution > wrote: > >> >> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution >> wrote: >> >> Stop me if you've heard this one; I've only just joined the list, in order >> to raise it. >> >> Here's a common thing to say: >> >>

Re: [swift-evolution] Philosophy of Swift

> On Jun 8, 2016, at 4:07 PM, Jordan Rose via swift-evolution > wrote: > > https://swift.org/about/ has some pretty good > verbiage about this. In particular: > > "Swift is a safe language." > > in that the obvious thing should be safe, and unsafe things should requ

Re: [swift-evolution] Philosophy of Swift

On Jun 8, 2016, at 6:13 PM, Dave Abrahams via swift-evolution wrote: > > on Wed Jun 08 2016, Paul Cantrell wrote: > >> The interplay of the first two and the last two is what makes the >> language unique. For example, structs have a simple, high-level >> programmer model — “pass by value seman

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

> On Jun 10, 2016, at 7:43 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu Jun 09 2016, Saagar Jha wrote: > >> Yes, that’s exactly my point. Force unwrapping optionals adds >> confusion for new users; all too often I see newcomers ending up with >> the assumption that the force unwr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution > wrote: > > Protocols are a mechanism for deriving types from each other whereas generics > are a way to parameterize types. My point was that Swift's other way to > parameterize types, namely by associated types, is very simil

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 10:50 AM, Matthew Johnson wrote: > >> >> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This has been a point of confusion for me as well. I keep hearing th

Re: [swift-evolution] Partial list of open Swift 3 design topics

Way back when, there was an unresolved discussion was about whether it’s a bug or a feature that $0 sometimes captures a single arg and sometimes captures all args as a tuple: http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/ https://bugs.swift.org/browse/SR-586 I mention th

Re: [swift-evolution] [Proposal draft] NSError bridging

> On Jun 27, 2016, at 1:17 PM, Douglas Gregor via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > The LocalizedError protocol describes an error that provides localized > messages for display to the end user, all of which provide default > implementations. The conforming type c

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

While it doesn’t give all the “raw value” functionality of enum, it’s possible to use object instance uniqueness to get enum-like behavior that can be extended: public protocol OpenEnum: class, Hashable { } extension OpenEnum { public var hashValue: Int { return ObjectIden

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

> On Jun 30, 2016, at 3:54 PM, Dan Appel wrote: > > That is the current workaround (as the proposal mentions), but it is still > missing support for enum features such as associated values and the pattern > matching power that they bring. Fair enough, it would be hard to generalize pattern ma

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

Where I’m going with my line of though is: 1. Extensible enums probably aren’t going to happen, for reasons mentioned earlier. 2. I don’t really see the protocol+structs approach as “emulating enums” at all. IMO, separate types are a more accurate model of what’s going on with the example you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? +1 Yes please. > * Is the problem being addressed significant enough to warrant a change > to Swift? Tuple ↔︎ arg conversion magic as it stands in the language is currently more confusing than useful. I’m in favor of all efforts to remov

Re: [swift-evolution] [Discussion] Determining argument count from context

This is filed here: https://bugs.swift.org/browse/SR-586 There was some discussion about it on the list about whether this is a bug or a dubious feature. Douglas Gregor recently weighed in on that: > I consider this a bug. The removal of implicit tuple splats should, IMO, > encompass makin

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

> * What is your evaluation of the proposal? +1, with bikeshedding. To me, “subclassable” does not imply “public.” If I hadn’t read this proposal, I would be likely to declare an internal class subclassable, and then be shocked when it was exposed as public! If it’s part of my public API, I w

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

> On Jul 5, 2016, at 8:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I think Kevin Lundberg is right to worry about testability, but I don't think > that has to prevent this change. Instead, we should permit `@testable` > imports to subclass/override things that are not publicly

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

> On Jul 6, 2016, at 3:41 PM, Goffredo Marocchi wrote: > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and more >> community-driven development, this concern is less sev

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

> On Jul 8, 2016, at 12:30 PM, Tino Heth via swift-evolution > wrote: > > Defaults matter, because they transmit a message: > Every rule and obstacle we add to Swift is a statement that says "we favor > bureaucracy over freedom", and this will affect the community evolving around > the langua

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution > wrote: > > 2. The motivation seems to be that it will force better API design. No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll address it. Accepting this prop

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0120: Revise 'partition' Method Signature

The proposal is clearly an improvement over the status quo. A naming concern, which I apologize for not getting in before the review period: In Ruby (and I think some other languages as well), “partition” returns two collections, one with the included elements and one with the excluded. That’s a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0120: Revise 'partition' Method Signature

> On Jul 12, 2016, at 7:27 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Jul 12 2016, Paul Cantrell wrote: > >> Does this proposal leave room for the two-collection variant if we >> want to add it later? … >> Overloading on return type is dicey business, especially when the type >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 4:39 PM, Chris Lattner wrote: > > To sum this all up, the core team is … requesting a revision to change the > concrete syntax to “public open class Foo” instead of “subclassable class > Foo”. Yes, +1 to “public open Foo” instead of “subclassable Foo”. Presumably “open”

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 5:56 PM, David Waite wrote: > > >> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner >> <mailto:clatt...@a

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Like others, I do find the details of this proposal hard to follow. It doesn’t seem like a simpler mental model for developers. However, I also find the current rules around extension access modifiers hard to follow. It’s confusing that “public extension” changes the default for members, when “

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> • What is your evaluation of the proposal? Breaking it down in parts: +1 to the basic principle of making the external subclassing a conscious, explicit API design decision. +1 to providing a design state for subclassability that leaves the most room for non-breaking future changes. Those w

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution > wrote: > > I wrote that subclassability is not an important element of safety > **independent of overriding**. If you don't allow any overriding, > your code is always “resilient” enough to handle subclassing. Code can make as

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

Strongly in favor. I agree that the existing behavior could even arguably be filed as a bug, since there is no static isValidCodePoint() method an API client can call first. Aside: I would still like to see String follow a similar convention of failing on initialization for UTF-16 strings conta

Re: [swift-evolution] Add AnyHashable to the standard library

> On Jul 22, 2016, at 6:15 PM, Erica Sadun via swift-evolution > wrote: > > On Jul 22, 2016, at 4:34 PM, Dmitri Gribenko via swift-evolution > wrote: >> >> You can view the full proposal here: >> https://github.com/apple/swift-evolution/pull/458/files >> >> Dmitri > > The proposal looks so

Re: [swift-evolution] Class scoped access level

I do certainly agree that 5 access levels are _plenty_, C++ “friend” is no great friend to me, and I too not want to see another one access level added. However, I do think there’s a related problem here worth solving. Sometimes, trying to break apart a large type using extensions, I encounter

Re: [swift-evolution] Class scoped access level

> On Sep 10, 2016, at 5:25 PM, Charles Srstka wrote: > >> On Sep 10, 2016, at 2:52 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Is that (i.e. having properties in extensions) listed in the completing >> generics manifesto? It certainly seems like it'd b

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

> On Aug 11, 2016, at 9:39 PM, Douglas Gregor via swift-evolution > wrote: > > FWIW, I'm planning to write a complete proposal for conditional conformances > and will start posting drafts once it is far enough along to be useful. I’m looking forward to that! I’ll throw a potential use case f

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

> On Sep 12, 2016, at 12:04 PM, Douglas Gregor wrote: > >> On Sep 12, 2016, at 8:14 AM, Paul Cantrell > > wrote: > >> // ...but this, oh dear: >> >> extension Optional.None: JSONRepresentable { } > > This will be ill-formed; Optional.None isn’t a type, it’s

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 29, 2016, at 11:14 AM, Joe Groff via swift-evolution > wrote: > >> On Aug 24, 2016, at 5:08 PM, Charles Srstka via swift-evolution >> wrote: >> >> PROPOSED SOLUTION: >> >> I propose the following operators: really_is, really_as, really_as?, and >> really_as!. These operators would

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Sep 12, 2016, at 4:01 PM, Joe Groff wrote: > > >> On Sep 12, 2016, at 12:24 PM, Paul Cantrell wrote: >> >> In Swift 2, this declaration ensured that callers used only objects as >> owners: >> >> func addObserver(observer: ResourceObserver, owner: AnyObject) >> >> In Swift 3, howe

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Sorry for the late arrival to this thread. Comments below… > On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev > wrote: > > What this proposal about is in one sense being able to export and share those > pins. This is a crucial and clarifying insight. It should be in the proposal

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 6:34 PM, Eloy Durán wrote: > >> I’m puzzled. If a package’s pinning does not affect any other package that >> uses it, why should the defaults be different? A library will still suffer >> from all the “works for me” problems an app might. >> >> Is the rationale that not

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar wrote: > >> On Oct 14, 2016, at 4:02 PM, Paul Cantrell wrote: >> >> I’m puzzled. If a package’s pinning does not affect any other package that >> uses it, why should the defaults be different? A library will still suffer >> from all the “works for

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 7:18 PM, Daniel Dunbar wrote: > >> >> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution >> wrote: >> >> That’s clearly a bigger, separate idea, not necessary to hash out right now. >> I mean it just to illustr

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

A late-arriving strong +1 for me. The index-related stuff is elegant and much needed. I’m surprised to learn that dict.keys and dict.values are copies and not already views! Clearly they should be. Question: I hit a closely related performance wall just last week, doing something like this:

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution > wrote: > > Let extensions introduce stored properties, but only in the same module as > the type’s definition. Then, the compiler can just take any extensions into > consideration when it’s determining the size of the type, ju

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

> On Oct 15, 2016, at 8:34 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Oct 14 2016, Paul Cantrell > wrote: > >> A late-arriving strong +1 for me. The index-related stuff is elegant and >> much needed. I’m surprised >> to learn that dict.keys

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 12:21 PM, Rob Mayoff via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > In any case, I’d specifically hate to lose these: > > - approximate equality: ≈ > - set operations: ∩, ∪ > - set

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution > wrote: > > However protocols nested inside types and types nested inside protocols is > still not supported, because protocols introduce a separate series of issues > involving associated types and the ’Self’ type. > > The har

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

I’d like to put in a word in appreciate of such a careful presentation of the idea. While it doesn’t change the fact that this is out of scope for Swift 4, it’s nice to read something so thoughtfully spelled out. Charlotte, I hope you’ll keep bringing your ideas. FWIW, while I rather like the t

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On Oct 24, 2016, at 4:43 PM, Slava Pestov wrote: > > >> On Oct 24, 2016, at 8:12 AM, Paul Cantrell wrote: >> >> >>> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution >>> wrote: >>> >>> However protocols nested inside types and types nested inside protocols is >>> still not

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

What is your evaluation of the proposal? General +1, with reservations. Novel elements of the proposed behavior will need careful evaluation and refinement as we see how they plays out in practice, with open-mindedness from both users and the core team. Breaking it down: +1 on having this feat

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

> On Nov 4, 2016, at 11:20 AM, Boris Buegling wrote: > >> On 4 Nov 2016, at 17:06, Paul Cantrell via swift-evolution >> wrote: >> >>> Overconstraint is much more of a risk in Swift than in other languages >>> using this style of package management.

Re: [swift-evolution] stored properties in extensions (was: associated objects)

extended. How would these properties play nice with an existing > definition of equality, for example? How can it be guaranteed that their > value is consistent with the remaining state? And kept that way in case of > mutability? > > -Thorsten > > > Am 15.10.2016 um 03

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

lay. > 2. To make auto pinning on by default, with an explicit mechanism for > projects to opt out. > > I hope to have this written up for review next week. > > Thanks! > - Daniel > >> On Nov 4, 2016, at 9:06 AM, Paul Cantrell via swift-evolution >>

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

Just a quick mini-review here; sorry, time pressure. This version of the proposal seems acceptable to me, though I have a nagging feel that it’s more complex than it needs to be. In particular, the two modes (autopin enabled / disabled) plus the --repin option seem to me to have a high confusio

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Dec 2, 2016, at 11:11 AM, Daniel Dunbar wrote: > > >> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This version of the proposal seems acceptable to me, though I have a nagging

Re: [swift-evolution] Generic types―covariance/contravariance

Siesta’s Entity would certainly profit from being able to opt in to this mechanism: https://bustoutsolutions.github.io/siesta/api/Structs/Entity.html It is _not_ a collection type and does not implement any collection-relat

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

> On Dec 17, 2015, at 4:08 AM, Jeremy Pereira > wrote: > > >> On 16 Dec 2015, at 19:52, Paul Cantrell via swift-evolution >> wrote: >> >> I do this a lot: >> >>for object in array ?? [] { >> >> …and it does impa

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

ten forces me to add additional parentheses — and not strong enough > to warrant an introduction of a new `in?` construct IMHO. > > — Radek > >> On 18 Dec 2015, at 21:56, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >

[swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

I was quite surprised to learn that it’s possible to create Swift strings that do not contain things other than valid Unicode characters. Is it feasible to guarantee that this cannot happen? String.init(bytes:encoding:) is failable, and does in fact validate that the given bytes are decodable w

Re: [swift-evolution] Proposal: Add .times method to Integer type

I’d be in favor of deferring this until other discussions about the ability to return/break/continue from closures play out. With that in place, there’s even the notion that for…in could be replaced by a library function. At that point, 5.times, or repeat(5) as a library call, would look a lot m

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

Er, typo in the first sentence! I meant to say: I was quite surprised to learn that it’s possible to create Swift strings that contain things other than valid Unicode characters. > On Dec 18, 2015, at 3:47 PM, Paul Cantrell via swift-evolution > wrote: > > I was quite surpri

Re: [swift-evolution] [Proposal] Lock file for Swift Package Manager

+1 for Ankit’s general idea. Details of the proposal aside, I’ll say from experience with bundler that it’s immensely useful — a lifesaver! — to know the exact version of the dependencies another author was using. This has saved my neck more than once. IMO it’s useful to have a lock file checke

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

Joe’s and Brent’s writeups copied below really get to the heart of this for me. This is a tough question, and I find myself torn. I’m sympathetic to both lines of argument. It’s not entirely true that “you can never take back” overridability — you can make a breaking API change with a new major

Re: [swift-evolution] Swift case conventions for Enums

On Dec 21, 2015, at 5:58 PM, Michael Wells via swift-evolution wrote: > > I love that Swift has a published API design guidelines at > https://swift.org/documentation/api-design-guidelines.html > , but one thing > about it bugs me: t

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

> On Dec 21, 2015, at 9:12 PM, Charles Srstka via swift-evolution > wrote: > > And my two cents is: > > NSError is antiquated, and enums conforming to ErrorType, with associated > types on the case values, are much better. They are cleaner, they are easier > to use, and they are nicer to loo

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

>> Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, >> I don't really see any reason to introduce a keyword other than >> associatedtype for this proposal. > > +1. associatedtype seems better than any other option I’ve seen thus far > (including the new ones you me

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

> On Dec 22, 2015, at 12:03 PM, Chris Lattner wrote: > >> On Dec 22, 2015, at 9:44 AM, David Owens II via swift-evolution >> wrote: >> >>> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution >>> wrote: >>> >>> Hmm, I wo

  1   2   >