Re: [swift-evolution] Public struct init is unexpectedly internal

> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution > wrote: > > So I’ve got this code in a package called “SomeLib": > public struct SomeType { > public var text = "SomeText" > } > and then, in another package, write this: > import SomeLib > print(SomeType().text) > and then r

Re: [swift-evolution] Public struct init is unexpectedly internal

> On Jan 30, 2017, at 1:30 AM, David Sweeris wrote: > > >> On Jan 30, 2017, at 1:21 AM, Slava Pestov > > wrote: >> >>> >>> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> So I’ve got this code in

Re: [swift-evolution] Warn about unused Optional.some(())

> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > Right now, expressions that evaluates to Optional<()>, > Optional>… gets special treatment when it’s unused. For example: > > func f(s: String) {} > let s: String = “” > s.map(f) // no warning here, even

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Feb 1, 2017, at 3:13 PM, David Hart > > wrote: >> >> Second question inline: >> >> >> >> Sent from my iPhone >> On 1 Feb 2017, at 23:09, David Hart > > w

Re: [swift-evolution] [apple/swift-evolution] Ease restrictions on protocol nesting (#552)

> On Feb 5, 2017, at 10:06 AM, Karl wrote: > > @slavapestov I can't reply to your comments > directly so will have do batch them here: > > With the current implementation of name lookup, qualified and unqualified > lookup will find the nominal type as a member

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

> On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution > wrote: > - Nested protocols in generic types are not parameterised by the parent's > generic parameters. So if I write GenericType.SomeProto and GenericType.SomeProto, is it the same protocol? What about GenericType.SomeProto, is

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

> On Feb 6, 2017, at 9:12 PM, Karl Wagner wrote: > > >> On 7 Feb 2017, at 06:05, Slava Pestov > > wrote: >> >>> >>> On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> - Nested protocols in generic types are

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

I really have nothing to add to this discussion, except for this fun fact: apparently, the backslash was added to ASCII so you could write /\ and \/ operators: http://www.bobbemer.com/BACSLASH.HTM Slava > On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swi

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 6:16 PM, Dany St-Amant via swift-evolution > wrote: > > > Le 7 févr. 2017 à 14:45, Robert Widmann via swift-evolution > mailto:swift-evolution@swift.org>> a écrit : > >> I lean +1, but this answer on its own seems incomplete. Exhaustiveness is >> an important property,

Re: [swift-evolution] Compile-time generic specialization

> On Feb 5, 2017, at 8:28 AM, Abe Schneider via swift-evolution > wrote: > The suggested method to get around this issue is to use a protocol to create > a witness table, allowing for runtime dispatch. However, this approach is not > ideal in all cases because: (a) the overhead of runtime dis

Re: [swift-evolution] Recursive protocol constraints

> On Feb 7, 2017, at 9:12 PM, Austin Zheng via swift-evolution > wrote: > > I would like to get the PR revised and into the review process soon, as it > should have been a month ago. Is there a good place to review the in-progress > work? I think it would go a long way to help complete the au

Re: [swift-evolution] I think we need more to our type calculus

> On Feb 8, 2017, at 12:09 PM, Daryle Walker via swift-evolution > wrote: > > I’ve been trying to get the maximum of a list of counts. I started by using > “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I > should really use the value closest to negative infinity as

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

Hah, Doug and I were just discussing this. In Swift 3.1, we generalized where clauses to allow them to add requirements on outer generic parameters. However we did not remove the diagnostic prohibiting a where clause from being attached to a non-generic method. In theory this can be made to wor

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

> On Feb 8, 2017, at 10:30 PM, Douglas Gregor wrote: > > >> On Feb 8, 2017, at 10:21 PM, Slava Pestov wrote: >> >> Hah, Doug and I were just discussing this. >> >> In Swift 3.1, we generalized where clauses to allow them to add requirements >> on outer generic parameters. However we did not

Re: [swift-evolution] array splatting for variadic parameters

Hi Dimitri, I think this is a desirable feature, but nobody has got around to designing and implementing it yet. Another case where it comes up is initializer inheritance. Suppose I have: class Base { init(x: Int…) {} } class Derived : Base { } Currently, Derived does not inherit Base.init(

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 8, 2017, at 1:34 AM, Tino Heth via swift-evolution > wrote: > > >> Allowing the omission of a default case in an exhaustive switch makes the >> addition of a new case to the enum a breaking change. > Depending on the context, even with a default the change might be breaking — > but

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 10, 2017, at 8:55 AM, Tino Heth <2...@gmx.de> wrote: > >>> I'm not sure if I like the concept of having two kinds of enum. >> >> Why not? Bool-like enums would be declared ‘closed’, and would not require a >> default case (but adding a new case would then break ABI). > > Well, enums a

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 2:41 PM, Karl Wagner via swift-evolution > wrote: > For example, the compiler squashes the layout of an enum in to the smallest > type which can represent all of its cases - so if you only have 2 cases, your > enum will be an Int1 (possibly stored in a way which overlaps

Re: [swift-evolution] [Pitch] consistent public access modifiers

Also, note that there will be at least one other similar annotation, but for structs — the evolution document calls it @fixedContents. We want a way to declare that the set of stored properties in a struct will never change, allowing clients to make assumptions about its layout. Unlike @closed e

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 13, 2017, at 6:50 AM, Adrian Zubarev via swift-evolution > wrote: > > Personally I’d prefer if we all together with the core team set down > (virtually ^^) and: > > Fully re-evaluated all the access modifier mess and sketched a new future > oriented model on how this should have bee

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > wrote: > > Lazy > > This one is clearer: if Joe Groff's property behaviors proposal from last > year is brought forward again, lazy can be demoted from a language keyword to > a Standard Library property behavior. If Joe or anyb

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 12, 2017, at 12:32 PM, David Hart via swift-evolution > wrote: > > Hi Matthew, > > Your arguments made sense to me. I modified the proposal to choose strategy > number 3: deprecating and removing class over several versions to favour > AnyObject. Mind having another proof read? > >

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

ulties in the language; it’s merely a syntactic quirk. I’m more concerned about banning protocols that inherit from typealiases that contain classes. Slava > > > -- > Adrian Zubarev > Sent with Airmail > > Am 14. Februar 2017 um 10:25:43, Slava Pestov via swift-evolu

Re: [swift-evolution] Does protocol support add to an object's size?

Values of concrete type always have the same size regardless of what protocols the type conforms to. Slava > On Feb 15, 2017, at 9:51 AM, Daryle Walker via swift-evolution > wrote: > > I don't know how protocol support works. I asking because I want to maintain > the stride of an array bein

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible future refinement of extensions

Re: [swift-evolution] final + lazy + fileprivate modifiers

While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here. I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language. It would make a lot more sense to just have internal and public

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution > wrote: > > >> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> As I have said elsewhere, I think the mental anguish mostly derives from the >> fact that scoped

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution > wrote: > >> >> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 16, 2017, at 4:28 PM, Matthew J

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:50 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Feb 16, 2017, at 4:37 PM, David Waite via swift-e

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:51 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:50 PM, Slava Pestov > <mailto:spes...@apple.com>> wrote: >> >>> >>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >>> mailto:swi

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:32 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 5:17 PM, Ben Cohen > > wrote: >> >> The win with mapping only the values is that the underlying hash table can >> retain the same physical layout, just with differ

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Now that I've thought more about it, I have a question. Escaping/unescaping >> is an important conc

Re: [swift-evolution] final + lazy + fileprivate modifiers

pen - the same as above, but outside the modules. >>>> >>>> To me, this way most people here will be happy: >>>> >>>> - those wishing the access control gets simplified - it in fact does, you >>>> don't need to use @protected, if

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

+1, two small questions: - If two cases have the same base name but different full names, will matching on the base name match both cases, or will it be an error? - What are the memory layout optimizations described here? From a first glance this looks purely syntactic. Slava > On Feb 17, 2017

Re: [swift-evolution] A concern

> On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution > wrote: > > Hello All, > > Its Sunday, time for some reflection... > > One of the big plusses of Objective-C was that the entire manual was just a > few pages long. I have not looked it up, but IIRC the entire manual > describing the

Re: [swift-evolution] 'Public' class visibility specifiers

> On Feb 20, 2017, at 8:47 AM, Joanna Carter via swift-evolution > wrote: > > OK, here comes the girl with the big wooden spoon to stir things up a bit ;-) > > When it comes to visibilities on classes, why, oh why do we have public vs > open *as well as* > the option of marking stuff as final

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

One example is that in Java, it is difficult to distinguish a failed hashtable lookup from a hashtable lookup that produced a value of null. In Swift, these would be modeled as .none and .some(.none), respectively. Slava > On Feb 21, 2017, at 8:36 AM, Joe Groff via swift-evolution > wrote: >

Re: [swift-evolution] [Discussion] Allowing extending existentials

> On Feb 21, 2017, at 10:53 PM, David Hart via swift-evolution > wrote: > > Hello list, > > Found out yesterday that you can’t extend all existentials in Swift: > > protocol P1 {} > extension P1 {} > // works as expected > > protocol P2 {} > extension P1 & P2 {} > // error: non-nominal type

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 21, 2017, at 11:05 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Evolutioniers, > > Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to > disambiguate references to functions. (You might've used it inside a > #selector expression.) But there's currently

Re: [swift-evolution] [Discussion] Allowing extending existentials

> On Feb 21, 2017, at 11:34 PM, Adrian Zubarev via swift-evolution > wrote: > > I’d love if we could extend the idea even further. It would be great to be > able to extend the typealias type, because it can be a more constrained type > (with a where clause). > > protocol P { > associated

Re: [swift-evolution] [Discussion] Allowing extending existentials

> On Feb 21, 2017, at 11:42 PM, David Hart via swift-evolution > wrote: > > If we drop the idea of extending Any and AnyObject (which is out of scope), > does the fact that what is left is syntactic sugar make it unsuitable for > Swift 4? I remember Chris saying syntactic sugar is not the goa

Re: [swift-evolution] Overloading Generic Types

> On Dec 23, 2016, at 12:32 PM, David Sweeris via swift-evolution > wrote: > > (I feel like I’ve already written this... I looked through my sent mail and > didn’t see anything, but my sincerest apologies if I started this thread a > month ago and forgot about it or something.) > > I no long

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 21, 2017, at 4:19 PM, David Waite via swift-evolution > wrote: > > >> On Feb 21, 2017, at 2:27 AM, Joanna Carter >> wrote: >> >> But in the Swift world, we now have the ability to extend almost any type, >> except Any and AnyObject, which appear to be protected by some deep and da

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 1:22 PM, David Sweeris via swift-evolution > wrote: > >> >> On Feb 22, 2017, at 12:21 PM, Huon Wilson > > wrote: >> >> >>> On Feb 22, 2017, at 10:20, David Sweeris via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> What if

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 3:39 PM, David Sweeris wrote: > >> >> On Feb 22, 2017, at 3:00 PM, Slava Pestov > > wrote: >> >> >>> On Dec 23, 2016, at 12:32 PM, David Sweeris via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> (I feel like I’ve alread

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

I think this is a manifestation of a more general problem, that default arguments cannot capture values from outer scope. Saying they’re evaluated in “type context” and not “instance context” is one way to skirt around the issue, but you can still trigger capturing anyway, and crash in SILGen:

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> On Mar 2, 2017, at 3:24 AM, Anton Zhilin via swift-evolution > wrote: > > I think that tuples should remain what they are now. Static-length vectors > should be types on their own and interact with tuples, with structs and with > Array<…> in the same way. > > newtype should be what enables

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

> On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution > wrote: > > I forget to mention, this should be also valid: > > let `42` = 42 > > print(`42`) > > struct A { > let `0` = 0 > } > > let number = A().0 > -1 This seems really confusing. extension Int { var `0`: Int { re

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

> On Mar 8, 2017, at 11:46 PM, Adrian Zubarev > wrote: > > I don’t have more precise examples except something like TCP socket error > codes as an enum. > I would expect that the error code is available as a computed property of the enum value, perhaps as its raw value or something else. I w

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were i

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

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] [Proposal] Foundation Swift Archival & Serialization

Hi Itai, I’m wondering what the motivation is for keeping this as part of Foundation and not the standard library. It seems like you’re landing an implementation of this in the Foundation overlay on master, and another copy of all the code will have to go into swift-corelibs-foundation. This se

Re: [swift-evolution] Swift's reflection

Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability. Slava > On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution > wrote: > > Hello fellow evolutionists, > > I’d like to ask i

Re: [swift-evolution] Revisiting 'T != Type' in where clause

Overload resolution has a lot of heuristics, but it’s not magic. It simply doesn’t know how to handle this case. I’d be in favor of consolidating and simplifying the overload resolution rules, with the goal of disambiguating common cases that are currently ambiguous. We might even be able to do

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:32 PM, Robert Bennett wrote: > > Agreed, I'm fine with a way of achieving this without T != Type. I suppose I > should have made the subject "Fix Swift's type checker in this particular > case". > > I still have trouble figuring out *how* it can correctly handle ambigu

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:36 PM, Jaden Geller wrote: > > >> On Mar 16, 2017, at 8:27 PM, Slava Pestov wrote: >> >> Overload resolution has a lot of heuristics, but it’s not magic. It simply >> doesn’t know how to handle this case. >> >> I’d be in favor of consolidating and simplifying the ove

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 4:00 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Mar 16, 2017, at 5:54 PM, Ben Rimmington wrote: >> >> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote:

<    1   2   3