Re: [swift-evolution] Protocol conformance error

I remember discussions on this list of curious situations in which a protocol doesn’t even conform to itself. This may be related. I’ll let others who better understand the type system and its limitations weigh in. P > On Jan 17, 2018, at 1:53 PM, Saagar Jha wrote: > > Interestingly, it seem

Re: [swift-evolution] Protocol conformance error

Note that it would be sound for the language to allow the opposite, which is called “contravariance” (the more specific type takes a more general input): protocol A {} protocol B: A {} protocol C { func test(x: B)// was A } class M: C { func test(x: A) {} /

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 11, 2018, at 11:42 PM, Brent Royal-Gordon > wrote: > >> On Jan 11, 2018, at 4:21 PM, Paul Cantrell > > wrote: >> >> This raises a question related to Chris’s: what is the utility of having >> Limb conform to a protocol instead of just providing allValues a

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

ause the values of x1 and x2 are now read in > rather than constants. > > -- Howard. > > On 11 Jan 2018, at 5:21 pm, Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >> >>> On Jan 10, 2018, at 10:21 PM, Chr

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

o abstract? I gave an example in my review of an enumerable thing where the items are analogous to cases but are not actually cases, and where I thought `allCases` would cause confusion but `allValues` would make sense: > On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution > wrot

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 10, 2018, at 2:23 PM, Kevin Nattinger wrote: > >> [...] >> >> I don’t agree that the Collection should be Int-indexed. Source-order is not >> a very strong guarantee IMO, and it wouldn’t be good if people started >> writing things like "MyEnum.allValues[3]” to reference a specific c

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 10, 2018, at 12:44 PM, Karl Wagner wrote: > > > >> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> What is your evaluation of the proposal? >> >> +1. Yes ple

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> What is your evaluation of the proposal? +1. Yes please. Long overdue. > Is the problem being addressed significant enough to warrant a change to > Swift? It’s a long-standing sore thumb. The proposal’s evidence of community demand fits my own experience: I’ve wanted this on multiple occasio

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:29 AM, Slava Pestov wrote: > >> On Dec 21, 2017, at 12:42 PM, Paul Cantrell > > wrote: >> >> 1. Presumably the portions of A inlined into B and C remain sensitive to the >> version-specific memory layout of A? Or will ABI stability mean that

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Thanks for the answers, Slava. More inline below. > On Dec 21, 2017, at 12:30 AM, Slava Pestov wrote: > > Hi Paul, > > Thanks for reviewing the proposal! > >> On Dec 20, 2017, at 9:21 PM, Paul Cantrell > > wrote: >> >> A concern: how would a library author reason ab

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

This seems like a problem worth solving — or rather worth making the solution public, since this is already in use as an undocumented feature! A concern: how would a library author reason about, and check for bugs in, the combinatorial explosion of old and new implementations that could exist s

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

Yes. If we’re fussing over the verb tense, “compacted” is clearly correct. Where did “compacting” come from? The API guidelines state: > Prefer to name the nonmutating variant using the verb’s past participle > (usually appending “ed”). …and (emphasis added): > When adding “ed” _is not gramma

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

> On Dec 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > > wrote: >> Just wan

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

I’m not at all a fan of _forcing_ IUOs. Depending on the application, return types of Self!, Self?, always-succeeds Self, Self + throws, or Self + fatalError could all be the best approach. In Python and JS, where objects have a dictionary-like shape, IUOs make sense: code can test for member p

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

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam wrote: > >> My main objection to the critical responses is that most of the objections >> are fundamentally cultural, not technical, and are fear-based, not >> evidence-based. > > The goal of this proposal is to bring people from a culture wher

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

> On Dec 6, 2017, at 8:52 PM, Joe DeCapo via swift-evolution > wrote: > > >> On Dec 6, 2017, at 5:46 PM, Letanyan Arumugam > > wrote: >> >> But IUO’s are marked with an “!” to differentiate it from a normal type, >> where as DynamicMemberLookup is just a normal p

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

> On Dec 3, 2017, at 1:26 PM, Chris Lattner via swift-evolution > wrote: > > On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp wrote: >> >>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution >>> wrote: >>> >>> That’s a good principle. However, a dynamic member lookup is just a member >>> lo

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

> On Dec 3, 2017, at 11:36 AM, Chris Lattner via swift-evolution > wrote: > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate logic. >>> It is immediately apparent from the APIs

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

> On Nov 30, 2017, at 3:40 PM, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 30, 2017, at 1:01 PM, Zach Wolfe > > wrote: >> >> Doug and others have brought up some great points, and I think Doug’s idea >> of a common infrastructure for impor

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

> On Nov 28, 2017, at 10:54 PM, Chris Lattner wrote: > >> On Nov 28, 2017, at 10:12 AM, Paul Cantrell > > wrote: >> Chris wrote: >>> Paul wrote: An “always use parens” bridge to Ruby has bad ergonomics Zero-arg Ruby methods are a mixture of property-like thi

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

I’m not sure this solves the Ruby ergonomics problem. Picking up from an earlier thread: Chris wrote: > Paul wrote: >> An “always use parens” bridge to Ruby has bad ergonomics >> Zero-arg Ruby methods are a mixture of property-like things that would >> certainly not use parens in Swift, and func

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

> On Nov 20, 2017, at 7:47 PM, Chris Lattner via swift-evolution > wrote: > >> On Nov 20, 2017, at 1:41 PM, David Waite >> wrote: >> >> In ruby, parens are optional. So, >> >> v = foo.value >> >> and >> >> v = foo.value() >> >> are identical. > > Ok, I wasn’t aware of that. It isn’t cl

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 7:08 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Nov 2017, at 12:34, Brent Royal-Gordon > > wrote: >> >>> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

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

> On Nov 18, 2017, at 1:44 AM, Jean-Daniel wrote: > > >> … >> >> In Ruby, `myObj.name()` is equivalent to `myObj.name`, and either works. In >> Swift, I don’t see that it’s possible to make both work with Chris’s >> proposal. > > IIUC, the goal is not to make swift look and behave the same

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

> On Nov 17, 2017, at 12:08 AM, Brent Royal-Gordon > wrote: > >> On Nov 16, 2017, at 1:44 PM, Paul Cantrell > > wrote: >> >> In the example you bring up: >> >>> you can write `def someMember` and `def someMember= (newValue)`) >> >> …there is no overloading. T

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

[Arg, I keep sending these with the wrong from address and getting bounced! Excited for Discourse…] > On Nov 16, 2017, at 12:00 AM, Brent Royal-Gordon via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution >> mailto

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

Interesting! I like the spirit of this proposal a lot. One question: presumably this behaves like Ruby’s method_missing in that any natively implemented members shadow the dynamic ones? i.e. Swift looks for a static match first, then uses the dynamicMember only as a fallback? I found myself ask

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution > wrote: > > I'd suggest `compactMap` as an alternative name, should `filterMap` find too > much resistance: I like that name too, though it’s probably my Ruby experience showing. I like the clarity of “compact” for nils, “filte

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

t 11:36 AM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: >>>> The problem in the Doodads example is that the name flatMap is used to >>>&g

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> What is your evaluation of the proposal? Strong approve. I would happily also accept name variants such as mapFilter — but I’m heartily in favor of _something_ that distinguishes _by name_ flattening sequences vs. filtering nils. > Is the problem being addressed significant enough to warrant

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] [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] [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 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

> 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] 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] 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

> 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

> 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] [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] [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] 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 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

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] 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] 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

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

> 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] [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] 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: 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] 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] 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] [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] [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] [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] [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-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] 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] [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] [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

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] 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

> 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] [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] [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] [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 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] [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] [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] 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

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] [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] [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 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

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] 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] 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] [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] [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] 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] 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] 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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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

> * 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] [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-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] 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] 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

  1   2   >