Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >> >> +1. Can you provide an example showing where you would place it though? > > Good question. Three

[swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Consistent formal type for 'self' in class methods Proposal: SE- Author: Slava Pestov Status: Awaiting review Review manager: TBD

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

nsion thereof, or not. The behavior when it > appears elsewhere is more general — we infer the parameters from the > surrounding expression, instead of assuming they’re equal to the context > parameters. > > This is a subtle change — definitely let me know if I’m not explaining

[swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

Simpler interpretation of a reference to a generic type with no arguments Proposal: SE- Author: Slava Pestov Status: Awaiting review Review

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

plaining it well. Slava > On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Simpler interpretation of a reference to a generic type with no arguments > > Proposal: SE- > <

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

gt;> … >> } >> } >> >> Basically the meaning of ‘GenericBox’ right now depends on whether it >> appears inside its own definition or extension thereof, or not. The behavior >> when it appears elsewhere is more general — we infer the parameters from

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

member immediately if I run into it in the future. > The current behavior appears broken to me. It will be great to have it fixed. > >> On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> On Apr 19, 2016, at 10:54 AM, Haravikk via swift-evolution > wrote: > Possibly optimisations unavailable to Array passing? Indeed, it should be possible to implement varargs by allocating the argument array on the stack (and having the compiler implicitly copy it

Re: [swift-evolution] [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev > wrote: > > > SE-0092 - Typealiases in protocols and protocol extensions > > SE-0102 - Remove @noreturn attribute

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution > wrote: > > Thanks for the concise and clear review of green threads :). I can understand > the concerns of runtime implementation when the runtime of the language is > replacing the kernel

Re: [swift-evolution] ABI in Layman's terms?

> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution > wrote: > > I'd also like to understand this more and this answer does not completely > satisfy me. I understand backwards compatibility, especially in terms of > source breaking changes. > > I have

Re: [swift-evolution] ABI in Layman's terms?

> On Aug 11, 2016, at 1:48 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] [Pitch] Rename Mirror

> On Jul 21, 2016, at 4:06 PM, Anton Zhilin via swift-evolution > wrote: > > 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko >: > > Mirror.DisplayStyle contains optional and set as special cases, but does not > > contain

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution > wrote: > >> >> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution >> wrote: >> >> The Rust language used to use a green thread model like Go (actually it >>

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 3:22 PM, David Sweeris <daveswee...@mac.com> wrote: > >> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> As I understand it, a big weakness of Go's model is that it does no

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

2016, at 4:24 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Aug 10, 2016, at 3:22 PM, David Sweeris <daveswee...@mac.com> wrote: >>> >>>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution

Re: [swift-evolution] PITCH: New :== operator for generic constraints

-1 — this adds a new syntax with little gain, and potentially a lot of additional complexity. > On Aug 16, 2016, at 2:49 PM, Charles Srstka via swift-evolution > wrote: > > Unfortunately, when this has come up on the list in the past, it has been > mentioned that

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:05 PM, Charles Srstka via swift-evolution > wrote: > >> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka >

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:40 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 8:13 PM, Slava Pestov > > wrote: >> >> -1 — this adds a new syntax with little gain, and potentially a lot of >> additional complexity. >>

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:51 PM, Slava Pestov wrote: > >> >> On Aug 16, 2016, at 6:40 PM, Charles Srstka > > wrote: >> >>> On Aug 16, 2016, at 8:13 PM, Slava Pestov >>

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 14, 2016, at 3:41 PM, Michael Savich via swift-evolution > wrote: > > What about having an InternalString subclass that only supports one encoding, > allowing it to be subscripted with Ints? The idea is that an InternalString > is for Strings that are more

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 17, 2016, at 11:36 AM, Charles Srstka via swift-evolution > wrote: > >> On Aug 17, 2016, at 12:02 PM, Vladimir.S via swift-evolution >> > wrote: >> >> On 17.08.2016 13:00, Boris Wang via

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

> On Aug 17, 2016, at 10:18 AM, Vladimir.S via swift-evolution > wrote: > But yes, strictly speaking 'make()->Circle?' conforms to protocol requirement > 'make()->Shape?', it does returns 'Shape?', so I believe this should be > treated as conformance to

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

Hi Russ, Keep in mind you can control layout of structs by defining them in C (using __attribute__((packed)) and so on), and using them as imported types in Swift. As Mark mentioned, we can add this later if we need it, so it’s probably out of scope for now. Slava > On Aug 17, 2016, at 11:28

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

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

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

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

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

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

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 > > a écrit : > >> I lean +1, but this answer on its own seems

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)

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

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

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 >

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

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution > wrote: > > So, 2 quick points: > > 1) I have often wanted a shorthand for expressing long tuples; I definitely > think that’s something worth bike-shedding, e.g. - (String * 4, Int32 * 4) or >

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 4:55 PM, Karl Wagner wrote: > > >> On 27 Jan 2017, at 22:25, Slava Pestov > > wrote: >> >> >>> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution >>>

Re: [swift-evolution] Subclass Existentials

This is a nice generalization of the existing protocol composition syntax. Implementation might get a little tricky — this touches a lot of things, such as inheritance clauses, constraints in generic signatures, and casts. It would require thorough testing. There are also a few odd corner

Re: [swift-evolution] extending typealiases

> On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution > wrote: > > In Swift 3.1, I was happy to see that we can now extend types with concrete > constraints. I think one other feature which fits nicely with this new > capability would be extending

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson

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

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

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

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

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 >

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

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 >> > wrote: >> >> Now that I've thought more about it, I have

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

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

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

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

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

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

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

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 >> > wrote: >> >> As I have said elsewhere, I think the

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,

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

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

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

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

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

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

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] Class and Subclass Existentials (Round 2)

es, this does not create any conceptual difficulties 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 u

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

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

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

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

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

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

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

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

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 >

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

- those wishing the access control gets simplified - it in fact does, you >>>> don't need to use @protected, if you don't want to/need to. >>>> - those who need a fine-grained solution, here it is. >>>> >>>> >>>> >>>>> On F

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] Will existentials ever conform to their protocols?

Yes, there’s already logic to detect and diagnose this case in fact (@objc protocols are self-conforming, except when they contain static members or initializers). Slava > On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution > wrote: > > There is also a

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

gt;>>> >>>>>> On Oct 24, 2016, at 4:43 PM, Slava Pestov <spes...@apple.com >>>>>> <mailto:spes...@apple.com>> wrote: >>>>>> >>>>>> >>>>>>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell &

Re: [swift-evolution] Will existentials ever conform to their protocols?

> On Jan 17, 2017, at 9:33 PM, David Sweeris via swift-evolution > wrote: > > > On Jan 17, 2017, at 22:30, Braeden Profile via swift-evolution > > wrote: > >> Hello Swift Community! >> >> I know that

Re: [swift-evolution] Swift Evolution Status Page Now Available

This looks great, thanks! SE-0080 was recently implemented by a contributor and will be available in Swift 4: https://github.com/apple/swift/pull/4314 Slava > On Jan 18, 2017, at 2:04 PM, Kyle Murray via swift-evolution > wrote: > > Hi everyone, > > We've just

Re: [swift-evolution] Availability checking of libraries (weak linking?)

Extending availability to support library versioning would be a great proposal. You should also take a look at the library evolution proposal, where this functionality will be required to implement the resilience model: https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst Slava

Re: [swift-evolution] Swift Evolution Status Page Now Available

Actually it’s available in swift-3.1-branch also. Kyle, do you mind updating this, or is there a way we can submit updates? Slava > On Jan 18, 2017, at 2:06 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > > This looks great, thanks! > &

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

Can we also add mention that default arguments on subscripts should work as well? This will force whoever implements this to do it properly and rip out the old RValue-based argument tuple emission that’s only used for subscripts in favor the argument emission logic. Slava > On Jan 19, 2017,

Re: [swift-evolution] Closures from methods with default args

> On Jan 19, 2017, at 9:07 PM, David Sweeris via swift-evolution > wrote: > It causes other issues, too. For instance, if we have > protocol Initable { init() } > And > struct Foo { init(_ x: Int = 0) {} } > We're left in an odd situation where `Foo` can't

Re: [swift-evolution] Assigning to 'self' in protocol extensions

> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution > wrote: > > From the perspective of the caller, I think, this behavior is > counterintuitive because we use "reference types" with an expectation: the > referencing address would never be changed

Re: [swift-evolution] Calling a Specific Implementation

> On Aug 18, 2016, at 8:21 PM, Ben Rimmington via swift-evolution > wrote: > > >> On 18 Aug 2016, at 16:32, John McCall wrote: >> >> Unapplied method references still dispatch down. It's a pretty simple >> experiment to run for yourself. > >

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 8:52 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 8:51 PM, Slava Pestov > > wrote: >> >> Here is why we must have that requirement. Consider the following code: >> >> protocol P { >> init()

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 10:16 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 11:42 PM, Slava Pestov > > wrote: >>> >>> Argh, that’s particularly frustrating since in something like ‘func foo>> P>(t: T)’ or ‘func foo(s:

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution > wrote: > > Opinions inline: > >> On 18 Aug 2016, at 07:43, Sikhapol Saijit via swift-evolution >> > wrote: >> >> Hi all, >> >> >>

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 1:42 AM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &

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

> On Oct 17, 2016, at 11:35 AM, Karl via swift-evolution > wrote: > > >> On 17 Oct 2016, at 20:31, Adrian Zubarev via swift-evolution >> > wrote: >> >> That’s also on the line: >>

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

Hi Karl, I just saw your draft after sending my first reply earlier; I posted some additional comments on the gist. Also I remembered that Jordan Rose and I were talking about this recently in the context of the ClangImporter, so I'm CCing him in case he wants to share some thoughts. > On

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

> On Nov 2, 2016, at 8:32 AM, Paul Cantrell <cantr...@pobox.com> wrote: > > >> On Oct 24, 2016, at 4:43 PM, Slava Pestov <spes...@apple.com> wrote: >> >> >>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell <cantr...@pobox.com> wrote: >&g

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

I could if there’s interest. Since we intend on maintaining source compatibility, it will not result in a simpler implementation, though, since we’ll need to keep the old code path around for Swift 3 mode. Still worth it? Slava > On Oct 11, 2016, at 1:58 PM, Pyry Jahkola

Re: [swift-evolution] Generic Subscripts

> On Jan 11, 2017, at 10:53 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 11, 2017, at 12:32 PM, Erica Sadun via swift-evolution >> > wrote: >> >> >>> On Jan 11, 2017, at 12:26 AM,

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 1:15 PM, Tony Allevato via swift-evolution > wrote: > > This is a request that comes up frequently; I wrote an early draft proposal > for it several months ago, with it covering all value types, not just enums, > and also including Hashable as

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 12:14 PM, Jonathan Hull via swift-evolution > wrote: > > I think the “when all their associated values were Equatable” is the > technical issue holding this type of thing up. The ability to spell that > type of thing is on the generics

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 2:30 PM, David Sweeris via swift-evolution > wrote: > > > On Jan 13, 2017, at 15:10, Anton Zhilin via swift-evolution > > wrote: > >> That seems pretty close to Rust’s derive. Why

Re: [swift-evolution] Generic Subscripts

> On Jan 12, 2017, at 7:05 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 12 Jan 2017, at 22:37, Slava Pestov via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>

Re: [swift-evolution] Generic Subscripts

> On Jan 12, 2017, at 9:53 AM, Chris Eidhof via swift-evolution > wrote: > > Ok, I've got a draft up as a gist: > https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 > > >

Re: [swift-evolution] Generic Subscripts

> On Jan 12, 2017, at 9:56 AM, Gwendal Roué via swift-evolution > wrote: > > Hello Chris, thanks for this draft! > > May I suggest that the introduction mentions genericity on return type as > well? > > subscript(_ index: Int) -> T > > (I have database rows

Re: [swift-evolution] Best way to handle escaping function that might throw

> On Jan 11, 2017, at 2:02 PM, Howard Lovatt via swift-evolution > wrote: > > Another possibility, other than generics, would be to drop rethrows all > together and have the compiler infer if a throw is possible or not, including: > > struct FStore { >

  1   2   3   >