Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

on Fri May 20 2016, plx wrote: >> On May 19, 2016, at 5:57 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue May 17 2016, Chris Lattner > >> > <mailto:swift-evolution@swift.org>> >> wrote: >> >>> Hello Swi

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

on Thu May 19 2016, Brent Royal-Gordon wrote: >> Why shouldn't this work with all Collections, with an optimized version >> for BidirectionalCollections? > > Why don't we have `index(before:)` on non-BidirectionalCollections? It's not > that you can't write it: > > func index(before index

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

ion@swift.org> wrote: > >> Excellent. Having one canonical, unambiguous way to get the string >> representation should make things simpler and easier for developers. >> >> Austin >> >> On Thu, May 19, 2016 at 3:57 PM, Dave Abrahams via swift-evolution < >>

[swift-evolution] [Review] SE-0093: Adding a public base property to slices

Hello Swift community, The review of "SE-0093: Adding a public base property to slices" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md Reviews are an important part of the Swift evolu

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

on Tue May 17 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0089: Renaming String.init(_: T)" begins now and > runs through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflectio

Re: [swift-evolution] Enhanced existential types proposal discussion

on Wed May 18 2016, Thorsten Seitz wrote: >> Am 18.05.2016 um 06:52 schrieb Austin Zheng via swift-evolution >> : >> >> >> > >>> On Tue, May 17, 2016 at 1:25 PM, Matthew Johnson >>> wrote: > > >> >> Within the angle brackets are zero or more 'clauses'. Clauses >> are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

on Wed May 18 2016, Erica Sadun wrote: >> On May 18, 2016, at 1:58 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On May 18, 2016, at 1:52 PM, Brent Royal-Gordon >>> wrote: >>> > > If we're doing this, I wonder if category 1 shouldn't just be `Convertible`. This woul

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

on Mon May 16 2016, Joe Groff wrote: > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly > what you'd expect, but does lead to problems when an 'as' expression > appears as part of a comparison: > > 20 as Int64 < y as Int64 // error, '>' expected to close generic > parame

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 16 2016, Matthew Johnson wrote: >> On May 16, 2016, at 10:14 AM, Dave Abrahams wrote: >> >> >> on Mon May 16 2016, Matthew Johnson wrote: >> > On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: on Fri May 13 2016, Matthew Johnson >>>

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

on Tue May 10 2016, Nate Cook wrote: > I've needed these in the past and used them in other languages—any feedback > on this idea? > > - > > Add last(where:) and lastIndex(where:

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Nate Cook wrote: >>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> on Mon May 09 2016, Nate Cook wrote: >>> >>> Yet another alternative would be to drop Set and Dictionary do

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 7:30 AM, Dave Abrahams wrote: >> >> >> on Mon May 09 2016, Joe Groff wrote: >> > On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution wrote: > * Operations that depend on sorted-ness and use bina

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Tue May 10 2016, Joe Groff wrote: >> On May 6, 2016, at 3:16 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and >> myself. > >> >> on Tue May 03 2016,

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 16 2016, Matthew Johnson wrote: >> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: >> >> >> on Fri May 13 2016, Matthew Johnson > > wrote: >> > If we’re going to hide the implementation details maybe it’s worth > taking advantage of the

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 16 2016, Tyler Fleming Cloutier wrote: >>> Super interesting talk! >>> >>> But consider: isn't a single value type able to represent *multiple* >>> ethereal types? >> >> “ethereal?” Does he really use that term? I don't know what it means. > > He does pretty frequently. He also r

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 15 2016, Tyler Fleming Cloutier wrote: >> This implies, therefore, that if salient attributes *define* the >> immutability of the value type, then the public interface is not >> guaranteed to be immutable, since it is allowed to include >> non-salient attributes. For example, a vector

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 15 2016, Tyler Fleming Cloutier wrote: > On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution > wrote: > > on Mon May 09 2016, Matthew Johnson wrote: > > On May 8, 2016, at 1:51 AM, Dave Abrahams > wrote: > >

Re: [swift-evolution] Removing "_ in" from empty closures

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution >> wrote: >> >> Currently if a closure takes a value, it requires "_ in" to note >> that the value is ignored. This makes sense in many cases, but >> creates a bit of a mess in the case of an e

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Fri May 13 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 13, 2016, at 9:12 AM, Dave Abrahams wrote: >> >> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> >>>My claim is that substituting the constraint of “it has value >>>semantics,” while presumably looser than

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Fri May 13 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 13, 2016, at 9:19 AM, Dave Abrahams wrote: >> >> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> >>>Remember that the only value semantic reference types are immutable, so >>>the struct rendition of such t

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 09 2016, Matthew Johnson wrote: >> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: >> >> >> on Sat May 07 2016, Andrew Trick wrote: >> > >>>On May 7, 2016, at 2:04 PM, Dave Abrahams wrote: >>> >>>2. Value types are not "pure" values if any part of the aggregate >>>

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Nate Cook wrote: >>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> on Mon May 09 2016, Nate Cook wrote: >>> >>> Yet another alternative would be to drop Set and Dictionary do

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 7:30 AM, Dave Abrahams wrote: >> >> >> on Mon May 09 2016, Joe Groff wrote: >> > On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution wrote: > * Operations that depend on sorted-ness and use bina

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Nate Cook wrote: > Yet another alternative would be to drop Set and Dictionary down a > level to a FiniteSequence protocol in between Sequence and > Collection. Basically none of the index-based collection APIs > (i.e. everything except `count` and `isEmpty`) make sense on se

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Joe Groff wrote: >> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> * Operations that depend on sorted-ness and use binary predicates should >>> not be available on all Collections; they're too easy to misuse, >>> they're hard to name we

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Brent Royal-Gordon wrote: >> * Operations that depend on sorted-ness and use binary predicates should >> not be available on all Collections; they're too easy to misuse, >> they're hard to name well, and as Nicola Salmoria has noted, they >> would not make any sense at all

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 09 2016, Matthew Johnson wrote: > Remember that the only value semantic reference types are immutable, so > the struct rendition of such types has only immutable properties. > Personally, I don't think that transforming > >struct X { > ... >

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 09 2016, Matthew Johnson wrote: > My claim is that substituting the constraint of “it has value > semantics,” while presumably looser than the PureValue constraint, would > not compromise the correctness of your view controller, so not only is > the meaning of PureValu

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Andrew Trick wrote: > On May 7, 2016, at 2:04 PM, Dave Abrahams wrote: > > 2. Value types are not "pure" values if any part of the aggregate > contains a > reference whose type does not have value semantics. > > Then Array is not a “pure” val

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: > On May 7, 2016, at 4:04 PM, Dave Abrahams wrote: > > on Sat May 07 2016, Matthew Johnson wrote: > > I've been thinking about this further and can now state my position > more > clearly > and concisely. > > 1.

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: >> >> You haven't answered this question. How would you use this protocol? > > I think the best example was given by Andy when discussing pure > functions. Maybe I want to write a generic function and ensure it is > pure. I can only do this if I kno

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: >> On May 7, 2016, at 3:03 PM, Dave Abrahams wrote: >> >> >> on Sat May 07 2016, Matthew Johnson wrote: >> >>> This depends on the type. For types representing resources, etc it works >>> just >>> fine. But for models it does not work unless the m

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Tyler Fleming Cloutier wrote: >> On May 7, 2016, at 12:52 PM, Dave Abrahams wrote: >> >> >> on Fri May 06 2016, Tyler Fleming Cloutier wrote: >> > >>> On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Tyler Fleming Cloutier wrote: > That is a drastic solution indeed! How would this impact things like > Array? While Array itself has value semantics, the aggregate > obviously does not as it contains references which usually be mutated > undern

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Tyler Fleming Cloutier wrote: > No, I'm sorry; this “deep-vs-shallow” thing is a fallacy that comes from > not understanding the boundaries of your value. Or, put more > solicitously: sure, you can look at the world that way, but it just > makes everything pro

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

#x27;t believe that introducing a “pure values” distinction is adding simplicity and clarity. To me it looks like a needless wrinkle. > Matthew > > Sent from my iPad > > On May 7, 2016, at 11:17 AM, Matthew Johnson wrote: > > Sent from my iPad > > On Ma

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: > Sent from my iPad > > On May 7, 2016, at 2:21 AM, Andrew Trick via swift-evolution > wrote: > > On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution > wrote: > > I don’t mean to

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Andrew Trick wrote: > On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution > wrote: > > I don’t mean to imply that it is the *only* valuable > property. However, it I (and many others) do believe it is an > extremely

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 6, 2016, at 8:54 PM, Dave Abrahams wrote: >> >> >>> on Fri May 06 2016, Matthew Johnson wrote: >>> >>>On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evol

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sat May 07 2016, Matthew Johnson wrote: > This depends on the type. For types representing resources, etc it works just > fine. But for models it does not work unless the model subgraph is entirely > immutable and instances are unique. > I agree that it isn't a good idea to provide a default

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Fri May 06 2016, Tyler Fleming Cloutier wrote: > On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution > wrote: > > on Fri May 06 2016, Matthew Johnson wrote: > > On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution > wrote

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

that's less clear. Just because we *can* do this doesn't mean we should. > On Sat, May 7, 2016 at 6:24 AM, Dave Abrahams via swift-evolution > wrote: > > on Tue May 03 2016, Chris Lattner > wrote: > > > Hello Swift community, > > >

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 06 2016, Kevin Ballard wrote: >> >> > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: >> >> On Fri, May 6,

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Fri May 06 2016, Matthew Johnson wrote: > On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu May 05 2016, Matthew Johnson wrote: > > On May 5, 2016, at 10:02 PM, Dave Abrahams > wrote: > >

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Erica Sadun wrote: > On May 6, 2016, at 6:27 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu May 05 2016, Erica Sadun > wrote: > > On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > wrote: &

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Matthew Johnson wrote: >> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri May 06 2016, Cole Campbell wrote: >> >>> I don't know if it's considered too late at this point to

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: >> On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote: >> > >> > on Wed May 04 2016, Chris Lattner wrote: >> > >> > > Propo

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 02:23 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 06 2016, Kevin Ballard wrote: >> >> > One idea that came out of the core team discussion was something like: >> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

on Wed May 04 2016, Colin Barrett wrote: >> Swift numeric types all currently have a family of conversion > initializers. In many use cases they leave a lot to be > desired. Initializing an integer type with a floating point value will > truncate any fractional portion of the number. Initializin

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

016, Matthew Johnson wrote: > > On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed May 04 2016, Matthew Johnson > wrote: > > On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Cole Campbell wrote: > I don't know if it's considered too late at this point to rename 'reduce', but > I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. > 'Fold' > is just as obvious a name as 'reduce', IMO (actually I even prefer > it). It's not,

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Thu May 05 2016, David Hart wrote: > If we are discussing naming changes to reduce, here's my personal opinion: > > * When I first encountered it, I understood exactly what it did because I knew > that term of art. If it was named sequence, I would have been > confused. Nobody's proposing to

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Thu May 05 2016, Erica Sadun wrote: > On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md > > Sequence.prefix(while:) & Sequence.drop(while:)

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Wed May 04 2016, Chris Lattner wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md > > Hello Swift Community, > > The review of SE-0045: "Add scan, prefix(while:), drop(while:), and > unfold to the stdlib" ran from April 2

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Fri May 06 2016, Nate Cook wrote: >> On May 6, 2016, at 4:20 PM, Dave Abrahams via swift-evolution >> wrote: >> >>> on Fri May 06 2016, Nate Cook wrote: >>> >>>How can you reverse a variable-length collection with a fixed number of

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and myself. on Tue May 03 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0074: Implementation of Binary Search functions" > begins now and runs through May 9. The proposal is available here: > >

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > One idea that came out of the core team discussion was something like: > > sequence(from: 0) { $0 += 42 } > > Since it returns a sequence. > > It just occurred to me that, if we follow existing naming conventions, this > function would end u

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Fri May 06 2016, Nate Cook wrote: > How can you reverse a variable-length collection with a fixed number of > iterations? Are you talking about loop unrolling in the library? > > I mean looping count / 2 times instead of looping while lowIndex < > highIndex, Why do you think that wil

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

on Tue May 03 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0073: Marking closures as executing exactly once" > begins now and runs through May 9. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Thu May 05 2016, Nate Cook wrote: > Thanks for the feedback, Dmitri &co, this all looks excellent! I'll work on > updating the proposal. > >> On May 5, 2016, at 6:13 PM, Dmitri Gribenko wrote: >> >> On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution >> wrote: >>> Hello Swif

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Thu May 05 2016, Matthew Johnson wrote: > On May 5, 2016, at 4:59 PM, Dave Abrahams wrote: > > on Wed May 04 2016, Matthew Johnson wrote: > > On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed May

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

on Wed May 04 2016, Erica Sadun wrote: > Having to figure out where a previously defaulted value should be inserted > when > adding an explicit setting imposes an undue burden on the programmer, reduces > flexibility during experimentation, and removes one of the neatest Swift > features. For t

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Thu May 05 2016, David Sweeris wrote: >> On May 5, 2016, at 5:01 PM, Dave Abrahams wrote: >> >> >> on Wed May 04 2016, David Sweeris wrote: >> > >>>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution >>>> wrote: >&g

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, David Sweeris wrote: >> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution >> wrote: >> >> In order for something like AnyValue to have meaning, we need to impose >> greater order. After thinking through many approaches over the y

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, Matthew Johnson wrote: > On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed May 04 2016, Matthew Johnson wrote: > > On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution &g

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Thu May 05 2016, Joe Groff wrote: >> On May 5, 2016, at 10:03 AM, Dave Abrahams wrote: >> >> >> on Thu May 05 2016, Joe Groff wrote: >> > On May 5, 2016, at 8:56 AM, Dave Abrahams wrote: on Wed May 04 2016, Joe Groff wrote: >>> >> On May 4, 2016, at 5:2

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Thu May 05 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 5, 2016, at 10:59 AM, Dave Abrahams wrote: >> >> >> on Wed May 04 2016, Matthew Johnson wrote: >> On May 4, 2016, at 4:16 PM, David Sweeris wrote: Having given it some more thought... Does "PureRefer

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Thu May 05 2016, Joe Groff wrote: >> On May 5, 2016, at 8:56 AM, Dave Abrahams wrote: >> >> >> on Wed May 04 2016, Joe Groff wrote: >> > On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution wrote: Something about your first paragraph reminded me of a questio

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Wed May 04 2016, Matthew Johnson wrote: >> On May 4, 2016, at 4:16 PM, David Sweeris wrote: >> >> Having given it some more thought... Does "PureReference" make >> sense? What would it mean? At some point a reference has to, you >> know, actually refer to a concrete value. Otherwise it's ju

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Wed May 04 2016, Joe Groff wrote: >> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution >> wrote: >> >> Something about your first paragraph reminded me of a question I've >> had for a while. Is there a reasoning behind not being able to >> restrict a protocol to value types? One

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

on Wed May 04 2016, "T.J. Usiyan" wrote: > Something about your first paragraph reminded me of a question I've had for a > while. Is there a reasoning behind not being able to restrict a protocol to > value types? There are two answers: 1. We haven't gotten around to it 2. As I mentioned els

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, Matthew Johnson wrote: >> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed May 04 2016, Adrian Zubarev wrote: >> > >>> Not sure what to think about the enum cases inside a protocol

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, Adrian Zubarev wrote: > Not sure what to think about the enum cases inside a protocol (if AnyEnum > would > even exist), it could be a nice addition to the language, but this is an own > proposal I guess. > > We should start by adding AnyValue protocol to which all value typ

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, David Waite wrote: > In my opinion, one problem is that we don’t have a reference to a > laundry or wish list of what features we would like around string > literals in the language. Without evaluating a proposal against all of > those features (moves forward, doesn’t impact,

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, Brent Royal-Gordon wrote: >> Second, this proposal should explain why it's reinventing the wheel >> instead of standardizing existing, very successful, prior art. > Answer >> the question: “what compelling advantages does this syntax have over >> Python's?” > > Sure. > > Firs

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

on Mon May 02 2016, David Hart wrote: > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I > mentioned in the Detail Design section that the following syntax be > valid: Total nitpick, but I just can't hold it in: I don't know why we're seeing propos

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 02 2016, David Sweeris wrote: > I was just thinking that: > > protocol Foo : reference {} > > might be more to the point than: > > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* > reference-semantics type of type in Swift, but

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

on Mon May 02 2016, Austin Zheng wrote: > +1. The force unwrap operator is basically a runtime assert that enforces the > invariant that "this value should not be nil at this point of use, and if it > is > nil the programmer made a mistake". It is a perfectly legitimate tool for > writing code

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

d Sweeris via swift-evolution > wrote: > > On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution > wrote: > > On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution > wrote: > >

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, David Sweeris wrote: > On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution > wrote: > > On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution > wrote: > > How does one distinguish between calls to a s

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Mon May 02 2016, Joe Groff wrote: >> On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon May 02 2016, Joe Groff wrote: >> > >>>> On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution >&

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution > wrote: > > Tony, thanks for writing this up! > > on Mon May 02 2016, Tony Allevato wrote: > > > Other kinds of operators (

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > Acknowledgments > > Thanks to Chris Lattner and Dave Abrahams for contributing to the early > discussions, particularly regarding the need to improve type checker > performance > by genericizing protocol-based operators. FWIW, I think you have omitted

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > Open issue: Class types and inheritance > > While this approach works well for value types, these static operators may not > work as expected for class types when inheritance is involved, and more work > may > be needed here. > > We can currently model

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Tony, thanks for writing this up! on Mon May 02 2016, Tony Allevato wrote: > Other kinds of operators (prefix, postfix, assignment) > > Static operator methods have the same signatures as their global counterparts. > So, for example, prefix and postfix operators as well as assignment operators

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

ve > > MemoryLayout.size > MemoryLayout.alignment > MemoryLayout.spacing > > -Dave > > > On Sun, May 1, 2016 at 21:41 Dave Abrahams via swift-evolution > > wrote: > > > > on Sun May 01 2016, Xiaodi Wu > wrote: >

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Mon May 02 2016, Joe Groff wrote: >> On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Sun May 01 2016, Xiaodi Wu wrote: >> > >>> It's a bad habit of mine, I guess, to err on the side of suggesting

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

otprint(of:) > Memory.alignment(of:) > Memory.spacing(of:) > ``` I'd rather have MemoryLayout.size MemoryLayout.alignment MemoryLayout.spacing -Dave > On Sun, May 1, 2016 at 21:41 Dave Abrahams via swift-evolution > wrote: > > on Sun May 01 2016, Xiaodi Wu

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Sun May 01 2016, Антон Жилин wrote: > Then why not rename stride(from:to:by:) to range(from:to:by:) ? > I think, range is closer to what people coming from other languages expect to > see. The main reason is that it doesn't produce a Range. “Range” already has a meaning in Swift, and it ain

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Sun May 01 2016, Xiaodi Wu wrote: > On Sun, May 1, 2016 at 7:00 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu Apr 28 2016, Xiaodi Wu > wrote: > > > We all know and love sizeof(), but given that it's different from its C > >

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Sun May 01 2016, Xiaodi Wu wrote: > On Sun, May 1, 2016 at 7:01 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun May 01 2016, Xiaodi Wu wrote: > > > A clash of names is inelegant, but in practice, I'm not actually sure > that > > th

Re: [swift-evolution] Protocol non-conformance clause

on Fri Apr 29 2016, Erica Sadun wrote: > Gmane is down as far as my browser is concerned and I haven't found anything > by > Googling. > > Given the following: > > protocol A {func foo()} > protocol B {} // empty protocol > > extension A where Self:B { > func foo() { > print("Self is B") > } >

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Sun May 01 2016, Xiaodi Wu wrote: > A clash of names is inelegant, but in practice, I'm not actually sure that > there's really a lack of clarity. IMO, `stride(of: Int)` is not really > misinterpretable as anything else. I disagree, especially since `Strideable` has an associated `Stride` ty

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

on Sun May 01 2016, Brent Royal-Gordon wrote: >> The proposal has been updated as per feedback from the core team > (https://github.com/apple/swift-evolution/pull/275). This includes > removing some last vestiges of Swift 2 naming as well as replacing > `iterate(_:apply:)` with an overloaded fun

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Thu Apr 28 2016, Xiaodi Wu wrote: > We all know and love sizeof(), but given that it's different from its C > counterpart anyway, shouldn't these conform to Swift naming guidelines? In > other > words, after SE-0006, shouldn't these names be as follows? > > ``` > size(of: T.Type) > size(ofVa

Re: [swift-evolution] multi-line string literals.

on Thu Apr 28 2016, Brent Royal-Gordon wrote: > Awesome. Some specific suggestions below, but feel free to iterate in a > pull > request if you prefer that. > > I've adopted these suggestions in some form, though I also ended up rewriting > the explanation of why the feature was designe

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, "Ted F.A. van Gaalen via swift-evolution" wrote: > @Dave also > what do you think about this? > I am trying to avoid the conclusion that most Swift-evolution > participants are very much FP biased. is this the case? I don't believe so. > (some have ventilated this befor

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

on Fri Apr 29 2016, Matthew Judge wrote: > I believe the following idea was brought up on the list the last time > this topic came up, but I think it has a number of advantages and gets > rid of the need for a 'required' keyword completely. I have > reservations on the 'override' keyword as well

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

on Fri Apr 29 2016, Kevin Ballard wrote: > On Fri, Apr 29, 2016, at 05:12 PM, Max Moiseev via swift-evolution wrote: >> HI all, >> >> >> After having discussed this proposal with the members of the standard >> library team, we would like to propose the following updates: >> >> - Since both the l

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

on Fri Apr 29 2016, Kevin Ballard wrote: > On Thu, Apr 28, 2016, at 11:11 AM, Chris Lattner via swift-evolution wrote: >> Hello Swift community, >> >> The review of "SE-0045: Add scan, prefix(while:), drop(while:), and iterate >> to the stdlib" begins now and runs through May 3. The proposal i

<    4   5   6   7   8   9   10   11   12   13   >