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

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

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

t; enhancements to the program because 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >

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

semantics of this protocol by making it so 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

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

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

> On Jan 10, 2018, at 12:44 PM, Karl Wagner <razie...@gmail.com> wrote: > > > >> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> What is you

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

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

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

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

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

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 >> > wrote: >> >> On Sat, Dec 9, 2017 at 11:20 Steven

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

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

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

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

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

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

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

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() >> >>

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

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

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

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 > > wrote: > >> On Nov 14, 2017, at 11:29 PM, Chris Lattner

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

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

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

wift.org>> wrote: >> >> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: &

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

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

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

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

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

Re: [swift-evolution] Revisiting SE-0110

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

Re: [swift-evolution] Revisiting SE-0110

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

Re: [swift-evolution] Revisiting SE-0110

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

Re: [swift-evolution] Revisiting SE-0110

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

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

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

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 > > wrote: > >> On Jun 16, 2017, at 8:44 AM, David Hart > > wrote: >> >> Okay, I undertand. I’m just worried that

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 >

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 >> > wrote: >> >> On 14.06.2017 21:23, Haravikk via swift-evolution

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

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

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

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

t; > Regards, > Austin > > On Mon, Jun 12, 2017 at 12:47 PM, Paul Cantrell via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution > > <swift-evol

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

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

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

an.dog...@gmail.com> wrote: > > this work, > > prefix operator * > > prefix func *<Root, Value>(keyPath: KeyPath<Root, Value>) -> (Root) -> Value { > return { $0[keyPath: keyPath] } > } > > ["Hello, World"].map(*\String.count)

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

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 >

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

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

> On May 7, 2017, at 6:01 AM, Jean-Daniel <mail...@xenonium.com> wrote: > >> >> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> >>&g

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

> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution > > wrote: > > >> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution >> > wrote: >> >> Concern:

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

ved 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 <rjmcc...@apple.com> wrote: > >> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution >> <swift-evolution

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

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

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

> On Dec 2, 2016, at 11:11 AM, Daniel Dunbar <daniel_dun...@apple.com> wrote: > > >> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> This version of

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

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

ncies > which come into play. > 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

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

ially wreak havoc with the semantics of the type > being 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 > mutabilit

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

> On Nov 4, 2016, at 11:20 AM, Boris Buegling <bbuegl...@apple.com> wrote: > >> On 4 Nov 2016, at 17:06, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> Overconstraint is much more of a risk in Swift than in oth

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

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

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

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

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 > > wrote: > In any case, I’d specifically hate to lose these: > > -

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

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 <daniel_dun...@apple.com> wrote: > >> >> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> That’s clearly a bigger, separate idea, not nec

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

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

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.

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,

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,

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

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

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 >> > wrote: >> >> Is that (i.e. having properties in extensions) listed in the completing

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

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

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

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 <da...@alkaline-solutions.com> wrote: > > >> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 1

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

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

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

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

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

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 <pana...@gmail.com> wrote: > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> In the era of increased open sourcing, easy forking, and more >

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

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

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

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

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

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 16, 2016, at 10:50 AM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Thi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> 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

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

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

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

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 > <swift-evolution@swift.org> wrote: > >> >> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w

  1   2   >