Re: [swift-evolution] Infer types of default function parameters

> On Mar 14, 2017, at 9:40 PM, Slava Pestov via swift-evolution > wrote: > > -1. > > We already have a related feature for stored properties in structs and > classes, and it causes a performance problem when compiling multi-file > modules in non-WMO mode. Suppose you have: > > — a.swift — >

Re: [swift-evolution] Infer types of default function parameters

-1. We already have a related feature for stored properties in structs and classes, and it causes a performance problem when compiling multi-file modules in non-WMO mode. Suppose you have: — a.swift — struct Box { var x = } — b.swift — func takesABox(_: Box) {} — c.swift — func returnsA

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On 15 Mar 2017, at 01:10, Jaden Geller via swift-evolution > wrote: > > If this were desired, an associated type would not be sufficient. Perhaps > `Dictionary` only supports keys where `Hash == Int`. Then any type that might > key a dictionary must use `Int` as it’s hash type. It wouldn’t

Re: [swift-evolution] [draft] Add `clamped(to:)` to the stdlib

I am starting to worry that I left something out. On Tue, Mar 14, 2017 at 11:16 AM, Nicholas Maccharoli wrote: > Swift-Evolution, > > After considering the indispensable feedback from the community here is a > slightly more polished draft. > > If anyone is interested the draft can be downloaded

Re: [swift-evolution] Property Selectors

+1 Lenses would be awesome! On Wed, Mar 15, 2017 at 1:59 AM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > Lenses ! My only concern is that > arbitrary effects can be attached to setters and getters, which can lead to > surprising res

Re: [swift-evolution] Pitch: Range return values for String Insert/Replace methods

Hi Charles, As part of the String redesign in Swift 4, these methods on String are intended to be part of String’s conformance to RangeReplaceableCollection. As such, this proposal should be phrased in terms of a change to that protocol, rather than to String. Couple of additional things to no

Re: [swift-evolution] Swift null safety questions

But - that would require a dedicated thread or a thread pool to run function calls on. Definitely it lacks many of the advantages of shared objects directly in the process. I would definitely prefer a small memory leak or inconsistent state. The server could handle existing requests and restart its

Re: [swift-evolution] [Draft] Hasher & HashVisitable

If this were desired, an associated type would not be sufficient. Perhaps `Dictionary` only supports keys where `Hash == Int`. Then any type that might key a dictionary must use `Int` as it’s hash type. It wouldn’t be possible to define a second implementation with `Int128` or any other types as

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

Hi Ankit, I like the proposal very much. One question about SystemPackageProvider: Sometimes it's neccessary to pass options to brew or apt-get, for example: brew install libxml2 --with-python Should they be added to package name or have a separate field? Adding the field in the future will bre

Re: [swift-evolution] [Draft] Hasher & HashVisitable

It would be possible for a Hasher to return varying types, but then people might want the interface to support cryptographic hashing as well as variable length hashes (for things like HAMT) -DW > On Mar 14, 2017, at 4:56 PM, Greg Parker via swift-evolution > wrote: > > >> On Mar 14, 2017, a

Re: [swift-evolution] Swift null safety questions

Also the proxies would need to implement some protocol so that they can be de-proxied when sent back to a shared method, and the proxy object exposed to the user with a new declaration that accepts only proxies. Like using MyClass -> MyClassSharedProxy for the proxy class and class MyClass {

Re: [swift-evolution] Swift null safety questions

Sounds like a good idea. I assume that Swift would need to compile these proxies in advance to be sub-classes ie. binary compatible objects that will forward calls and return proxies. “Value” types can be copied as they normally are, or wrapped by the user (along with “final” objects which could be

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 14, 2017, at 12:01 PM, David Sweeris via swift-evolution > wrote: > > Are we committed to having `hashValue` always be an `Int`, or could it be an > associated type like `(Int, Int, Int, Int)`? Seems like especially for > something like a BigNum type or an Array, there might simple

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 14, 2017, at 2:36 PM, Vincent Esche > wrote: > > Pardon my ignorance here, but shouldn’t `foo(t: T)` always > monomorphize due to being generic? Isn’t that how `T: …` differs from, say > `foo(t: Protocol)`? The compiler ought to be able to monomorphize either signature, given that i

Re: [swift-evolution] [Draft] Hasher & HashVisitable

Pardon my ignorance here, but shouldn’t `foo(t: T)` always monomorphize due to being generic? Isn’t that how `T: …` differs from, say `foo(t: Protocol)`? On Tue, Mar 14, 2017 at 7:30 PM, Joe Groff wrote: > > > On Mar 14, 2017, at 11:27 AM, David Hart wrote: > > > > > > > >> On 14 Mar 2017, at 1

Re: [swift-evolution] where clauses on enum cases

> On Mar 14, 2017, at 12:58 PM, Slava Pestov via swift-evolution > wrote: > > You’re asking for GADTs: > https://en.wikipedia.org/wiki/Generalized_algebraic_data_type > > This feature is difficult to implement correctly and efficiently and I doubt > Swift will ever support it, but you never

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 14, 2017, at 1:08 PM, Karl Wagner wrote: > > >> On 14 Mar 2017, at 19:30, Joe Groff via swift-evolution >> wrote: >> >> >>> On Mar 14, 2017, at 11:27 AM, David Hart wrote: >>> >>> >>> On 14 Mar 2017, at 16:41, Joe Groff via swift-evolution wrote: > O

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On 14 Mar 2017, at 19:30, Joe Groff via swift-evolution > wrote: > > >> On Mar 14, 2017, at 11:27 AM, David Hart wrote: >> >> >> >>> On 14 Mar 2017, at 16:41, Joe Groff via swift-evolution >>> wrote: >>> >>> On Mar 13, 2017, at 8:38 AM, Vincent Esche via swift-evolution w

Re: [swift-evolution] where clauses on enum cases

You’re asking for GADTs: https://en.wikipedia.org/wiki/Generalized_algebraic_data_type This feature is difficult to implement correctly and efficiently and I doubt Swift will ever support it, but you never know… Slava > On Mar 14

[swift-evolution] where clauses on enum cases

I've run into a problem recently when using generics with enums where I'm required to specify the type for a generic that isn't used for the enum case that's constructed. Example: protocol Mapping { associatedtype Destination } enum EvictionPolicy { case append case replace } enum M

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 13, 2017, at 8:38 AM, Vincent Esche via swift-evolution > wrote: > > Hi there, > > I've written up a proposal for an overhaul/replacement of the Hashable > protocol and would love to hear your feedback on it! > > Rendered >

Re: [swift-evolution] [Idea] Generic associated types

> On Mar 14, 2017, at 2:42 PM, Karl Wagner wrote: > I was thinking of making a new thread for this, but since this discussion’s > basically over I thought I’d ask a quick question about generic closures. > > Basically, I would like to express something like the following (without > type-erasing

Re: [swift-evolution] [Idea] Generic associated types

I was thinking of making a new thread for this, but since this discussion’s basically over I thought I’d ask a quick question about generic closures. Basically, I would like to express something like the following (without type-erasing via AnyCollection): func vendsGenericBytes(callback: (_: T)

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 14, 2017, at 11:27 AM, David Hart wrote: > > > >> On 14 Mar 2017, at 16:41, Joe Groff via swift-evolution >> wrote: >> >> >>> On Mar 13, 2017, at 8:38 AM, Vincent Esche via swift-evolution >>> wrote: >>> >>> Source compatibility >>> >>> Making use of "extending protocols to co

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On 14 Mar 2017, at 16:41, Joe Groff via swift-evolution > wrote: > > >> On Mar 13, 2017, at 8:38 AM, Vincent Esche via swift-evolution >> wrote: >> >> Source compatibility >> >> Making use of "extending protocols to conform to protocols": >> >> extension Hashable: HashVisitable >> { >

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 14, 2017, at 10:00 AM, Vladimir.S wrote: > > On 14.03.2017 18:34, Joe Groff via swift-evolution wrote: >> >>> On Mar 13, 2017, at 10:54 AM, Sean Heber via swift-evolution >>> wrote: >>> >>> I’m dumb when it comes to proper hashing, but it’s such a tediously >>> common thing in my exp

Re: [swift-evolution] [Draft] Hasher & HashVisitable

On 14.03.2017 18:34, Joe Groff via swift-evolution wrote: On Mar 13, 2017, at 10:54 AM, Sean Heber via swift-evolution wrote: I’m dumb when it comes to proper hashing, but it’s such a tediously common thing in my experience to need to add Hashable to some kind of a struct so I can stash it in

Re: [swift-evolution] Property Selectors

Lenses ! My only concern is that arbitrary effects can be attached to setters and getters, which can lead to surprising results when using the property reference. As a language feature, I’d be interested to see where discussion around this will lead. ~Robert

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md > > Thanks for this feedback. We'll revise it to "from:

[swift-evolution] Pitch: Range return values for String Insert/Replace methods

MOTIVATION: Swift strings support a few methods for inserting and replacing things in the middle of them: mutating func insert(_ newElement: Character, at i: String.Index) mutating func insert(contentsOf newElements: S, at i: String.Index) mutating func replaceSubrange(_ bounds: ClosedRange, w

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 13, 2017, at 8:38 AM, Vincent Esche via swift-evolution > wrote: > > Source compatibility > > Making use of "extending protocols to conform to protocols": > > extension Hashable: HashVisitable > { > > func hash(_ hasher: inout > H) { > > self.hashValue.hash(& > hasher

Re: [swift-evolution] [Draft] Hasher & HashVisitable

> On Mar 13, 2017, at 10:54 AM, Sean Heber via swift-evolution > wrote: > > I’m dumb when it comes to proper hashing, but it’s such a tediously common > thing in my experience to need to add Hashable to some kind of a struct so I > can stash it in a set or use it as a dictionary key. Is there

Re: [swift-evolution] Property Selectors

Ah, yes! That whole sleep thing really does help. Sent from my iPhone > On Mar 14, 2017, at 03:51, jaden.gel...@gmail.com wrote: > > > >> On Mar 14, 2017, at 1:42 AM, David Sweeris via swift-evolution >> wrote: >> >> >> >> >> Sent from my iPhone >>> On Mar 14, 2017, at 01:02, Andrew Thom

[swift-evolution] Range.mapRange -> Range

I’d like to propose we add a function to Range which allows transforming its bounds (both bounds, by the same transform). This would come in handy in many situations involving type conversions or bounds mutations: // duplicated on CountableRange extension Range { func mapRange(_ transform: (Bo

Re: [swift-evolution] [Draft Proposal] Improve protocol inheritance behaviour

The way I want things to work, “super” always calls the superclass’s method with matching name and signature. For the scenario you outlined, the superclass defines such a method, so it gets called. For the situation relevant to this proposal, if the superclass *obtains* such a method via default i

Re: [swift-evolution] [Draft Proposal] Improve protocol inheritance behaviour

So having a little more of a think about this what should happen in this situation: class A { func method() { print("A") } } protocol P { func method() } extension P { func method() { print("P") } } class B: A, P { override func method() { super.m

Re: [swift-evolution] [Draft Proposal] Improve protocol inheritance behaviour

So I did consider using the 'override' keyword, but it then raised the question as to what should happen when 'super' is called. I agree that by adding 'override' it makes it more obvious that you are overriding an existing implementation of the method, regardless of if it's defined in the class y

Re: [swift-evolution] Property Selectors

> On Mar 14, 2017, at 1:42 AM, David Sweeris via swift-evolution > wrote: > > > > > Sent from my iPhone >> On Mar 14, 2017, at 01:02, Andrew Thompson via swift-evolution >> wrote: >> >> Hello Swift Evolution Community, >> >> I’ve been thinking about a new language feature that would all

Re: [swift-evolution] Inconsistencies in recursive types

> On Mar 14, 2017, at 2:13 AM, Dimitri Racordon > wrote: > > Thanks a lot for your very detailed explanations! > > So my only issue regarding #1 #2 and #3 is the error message, which really > doesn't suggest the actual underlying problem. > > Regarding #5 and #6, I still feel like the compil

Re: [swift-evolution] Inconsistencies in recursive types

Thanks a lot for your very detailed explanations! So my only issue regarding #1 #2 and #3 is the error message, which really doesn't suggest the actual underlying problem. Regarding #5 and #6, I still feel like the compiler should complain about it. I disagree on the fact that it shouldn't be i

Re: [swift-evolution] [Draft] Hasher & HashVisitable

Turns out I’m rather bad at mailing lists. Hit “reply” (vs. "reply all") again. On Tue, Mar 14, 2017 at 3:34 AM, Károly Lőrentey wrote: > > On 2017. Mar 13., at 23:56, Vincent Esche gmail.com> wrote: > > On Mon, Mar 13, 2017 at 9:56 PM, Károly Lőrentey > wrote: > >> Yes please! I’ve a package

Re: [swift-evolution] Property Selectors

Sent from my iPhone > On Mar 14, 2017, at 01:02, Andrew Thompson via swift-evolution > wrote: > > Hello Swift Evolution Community, > > I’ve been thinking about a new language feature that would allow properties > to be first class citizens. The basic idea is as follows: > >let x: Prope

Re: [swift-evolution] [Draft] Hasher & HashVisitable

The documentation bug is not the sole motivation for the proposal. I did in fact only find it while writing the accompanying blog post , in which I present a couple of additional motivations besides hash collisions. Namely: - decoupling

[swift-evolution] Property Selectors

Hello Swift Evolution Community, I’ve been thinking about a new language feature that would allow properties to be first class citizens. The basic idea is as follows: let x: PropertySelector = #property(UIView.frame.origin.x) let view: UIView = … view.frame.origin.x = 20

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

Yep, after does sound confusing. I prefer from. > On 14 Mar 2017, at 08:22, Ankit Aggarwal via swift-evolution > wrote: > > Hi, > >> – Dave Sweeris' point about this reading wrong in English as >> .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us >> too. As a result, w

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

Hi, > – Dave Sweeris' point about this reading wrong in English as > .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us too. > As a result, we're going to clarify this by changing it to > .upToNextMajor(after:"x.y.z") and .upToNextMinor(after:"x.y.z"). The "after" in .up