Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

On Mon, Jan 8, 2018 at 4:29 PM, Ben Cohen via swift-evolution wrote: > There exists in the standard library a type `DictionaryLiteral` that deserves > naming re-consideration before we declare ABI Stability, because it’s > confusingly misnamed, being neither a

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

On Wed, Aug 10, 2016 at 3:50 PM, David Sweeris via swift-evolution wrote: > For example, maybe you really do need to interpret a 64-bit chunk of data as > an Int64, even though the compiler is convinced it’s a Double. We can do that > in Swift through the various

Re: [swift-evolution] MemoryLayout for a value

On Fri, Aug 5, 2016 at 7:35 PM, Boris Wang via swift-evolution wrote: > codes in swift REPL: > > protocol P { > var x:Int {get} > } > MemoryLayout.size > //r0 : Int = 40 > > struct S1 { > var v1:Int = 0 > } > MemoryLayout.size > //r1: Int =8 > > struct S2: P { > var v2:

Re: [swift-evolution] MemoryLayout for a value

On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution wrote: > Could I suggest an alternative? It's conservative in that it mimics the > relationships we had before the proposal was implemented and also maintains > the simplicity of the caseless enum: > > ``` >

Re: [swift-evolution] [Swift 3?] Add ContiguousArray -> Array non-copying initialiser

On Thu, Jul 28, 2016 at 11:01 AM, Karl Wagner wrote: > I didn't know that normally-copying initialiser was non-copying for > ContiguousArray. That's the kind of thing we should really document > somewhere We would welcome a patch for the docs! > (or it should be it's own

Re: [swift-evolution] [Swift 3?] Add ContiguousArray -> Array non-copying initialiser

On Wed, Jul 27, 2016 at 11:08 PM, Karl via swift-evolution wrote: > It seems like a reasonably large hole with a simple fix. Going from > ContiguousArray to Array is a kind-of upcasting conversion and should be > allowed -- it seems like that's almost the whole point of

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

On Mon, Jul 25, 2016 at 1:12 PM, Nate Cook via swift-evolution wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md > > +1! > > This proposal looks great to me. I only have one nitpick: it looks like > there's a

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

On Mon, Jul 25, 2016 at 1:34 PM, Pyry Jahkola via swift-evolution wrote: > > On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0131: Add AnyHashable to the standard library"

Re: [swift-evolution] Add AnyHashable to the standard library

You can view the full proposal here: https://github.com/apple/swift-evolution/pull/458/files Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ ___

[swift-evolution] Add AnyHashable to the standard library

Hi, The implementation of SE-0116 "Import Objective-C id as Swift Any type" requires a type-erased container for hashable values. We are proposing to add such a type-erased container under the name AnyHashable to the standard library. This proposal is additive, source-breaking changes are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution wrote: > I have been looking at the parts of this proposal related to > withUnsafe[Mutable]Pointer: > [...] I agree with everything that Bob said, and I would like to comment on this part: >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:38 AM, Nevin Brackett-Rozinsky wrote: > Excellent point Karl. > > In my view, floating point NaN values are really quite similar to `.none`. > > I would be interested in exploring a move *away* from the IEEE 754 handling > of NaN. In

Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

On Fri, Jul 22, 2016 at 8:23 AM, Félix Cloutier wrote: > I agree on principle for moving it out of stdlib, but what's the Objective-C > overlay? It is the overlay for the 'ObjectiveC' module where NSObject is defined. Dmitri --

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 2:13 AM, Pyry Jahkola via swift-evolution wrote: > 5. Will it be considered "ok" to define a type for which `T.areSame(a, b) == > true` but `a != b`? An obvious example would be Double.nan, so I assume the > answer is a resounding yes. Yes,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Thu, Jul 21, 2016 at 11:09 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 21, 2016, at 6:11 PM, Robert Widmann via swift-evolution >> wrote: >> >> Hello Swift Community, >> >> Harlan Haskins, Jaden Geller, and I have been

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Thu, Jul 21, 2016 at 10:17 PM, Xiaodi Wu wrote: > Robert, the gist is notably vague on this point, so I'm hoping you will > clarify. Are you proposing that FloatingPoint will break with IEEE754 > semantics? What will be the result of `Float.nan == Float.nan`? > > (My guess

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

On Thu, Jul 21, 2016 at 4:49 PM, Anton Zhilin wrote: > 2016-07-22 2:39 GMT+03:00 Dmitri Gribenko : >> >> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin >> wrote: >> > Moreover, types can completely customize contents of their >>

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

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

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

On Thu, Jul 21, 2016 at 3:25 PM, Anton Zhilin via swift-evolution wrote: > https://github.com/Anton3/swift-evolution/blob/master/proposals/-rename-mirror.md > > Rename Mirror > > Proposal: SE- > Author: Anton Zhilin, Adrian Zubarev > Status: Awaiting review >

Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

On Thu, Jul 21, 2016 at 10:02 AM, Michael Gottesman via swift-evolution wrote: > Hello everyone. > > This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore > to the Objective C overlay. +1. Dmitri --

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

On Mon, Jul 18, 2016 at 3:29 PM, Dave Abrahams via swift-evolution wrote: > > on Mon Jul 18 2016, Kevin Nattinger wrote: > >> I agree, true is definitely the expected behavior. In particular, it >> seems absurd to me that `a.hasPrefix(b)` and

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

On Tue, Jul 19, 2016 at 10:50 PM, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The review of "SE-0122: Use colons for subscript declarations " begins now > and runs through July 24. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

On Tue, Jul 19, 2016 at 10:51 PM, Chris Lattner wrote: > The review of "SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced" > begins now and runs through July 22. The proposal is available here: > > >

Re: [swift-evolution] : [Proposal] Change UnicodeScalar initializer to failable

On Tue, Jul 19, 2016 at 10:14 AM, Xin Tong via swift-evolution wrote: > Hi, > > I would like to propose changing unicodescalar initializer to failable. > > Currently, when you pass an invalid value to the UnicodeScalar initializer > the swift stdlib crashes the program

Re: [swift-evolution] [Pitch] Set of AnyObject by reference

On Sun, Jul 17, 2016 at 2:00 AM, 张国晔 via swift-evolution wrote: > I'm building an document-based app, and I'm having a problem regarding to Set. > > What I hope to achieve is to have a Set of unique objects by their references. Try this: public final class

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via swift-evolution wrote: > ## Proposed solution > > Replace `isUniquelyReferenced` by > `isUniquelyReferencedUnsafe` and remove the `NonObjectiveCBase` > class from the standard library. Thank you for this

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev wrote: > Good question. > > Dave/Dmitri: do you have a recommendation here? I can see either the JIRA > issues referencing the proposal (if one exists) or updating the gist. I > prefer the former. Updating the

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

On Wed, Jul 13, 2016 at 4:39 PM, Arnold Schwaighofer via swift-evolution wrote: > Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a > 'bitPattern:’ label to make it clear at the use site that we interpret the > value as a bit pattern. +1!

[swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

Hi, I'd like to continue the discussion of the issue raised by David Waite inhttp://thread.gmane.org/gmane.comp.lang.swift.evolution/21295/: > My main motivation for proposing this is the potential for developer > confusion. As stated during one of the previous threads on the naming of map, >

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

On Thu, Jul 7, 2016 at 6:14 PM, Dave Abrahams via swift-evolution wrote: > > on Wed Jul 06 2016, Tim Vermeulen wrote: > >> This is a follow up from this swift-users thread: >>

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

On Thu, Jul 7, 2016 at 9:27 AM, John McCall <rjmcc...@apple.com> wrote: > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote: >> Proposal link: >> >> >> https://github.com/apple/swift-evolution/blob/ma

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md Dave, Max and I discussed SE-0077 and reviewed the names of precedence groups. Here's our recommendation. In general, we think some names don't read well and have some ambiguities, for

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

On Wed, Jul 6, 2016 at 9:57 PM, Charlie Monroe via swift-evolution wrote: > > On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution > wrote: > > > On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution >

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 6:15 PM, Karl wrote: > > On 7 Jul 2016, at 02:06, Dmitri Gribenko wrote: > > On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote: > > I had a PR open for this which added a Collection specialisation, but you > said this

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote: > I had a PR open for this which added a Collection specialisation, but you > said this could be handled in a more general way which allows for more > optimised mutations. I’m curious how this would work; how does >

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 11:30 AM, Harlan Haskins wrote: > I’ve also seen unsafeAddressOf(_:) used when interfacing with C function > pointers when the lifetime of an object is guaranteed. Many C APIs vend an > API like: > > void perform_action(void (*callback)(void

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner <clatt...@apple.com> wrote: > On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote: >> >> Hi swift-evolution, >> >> Dave, Max and I have compiled a list of open i

[swift-evolution] Open Issues Affecting Standard Library API Stability

Hi swift-evolution, Dave, Max and I have compiled a list of open issues in the standard library for which the resolutions could result non-additive API changes. Having a resolution (and an implementation of the resolution!) for these issues is blocking API stability.

Re: [swift-evolution] [Idea] Large integer literals

On Sun, Jul 3, 2016 at 9:20 PM, Brent Royal-Gordon via swift-evolution wrote: > 2. Use a tuple/array of `Int`s/`UInts` > > Like `String`, this lends itself to becoming variable-width in a later > version; unlike `String`, it's relatively compact. But also unlike

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

On Fri, Jul 1, 2016 at 1:35 PM, Dave Abrahams via swift-evolution wrote: > I think if `Syntax.IntegerLiteral` is actually unclear then the best > cure is `ExpressibleAsIntegerLiteral` (no namespace needed). None of > the other suggestions I've seen describe what the

Re: [swift-evolution] renaming CustomStringConvertible

On Fri, Jul 1, 2016 at 12:48 PM, Vladimir.S <sva...@gmail.com> wrote: > On 01.07.2016 22:22, Dmitri Gribenko via swift-evolution wrote: >> >> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution >> <swift-evolution@swift.org> wrote: >>> >

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

On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote: > > > I'm not sure I really want '.url' and '.stringEncoding' on every > Error. '

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

On Mon, Jun 27, 2016 at 11:17 AM, Douglas Gregor via swift-evolution wrote: > extension ErrorProtocol { > // Note: for exposition only. Not actual API. > private var userInfo: [NSObject : AnyObject] { > return (self as! NSError).userInfo > } > > var

Re: [swift-evolution] Partial list of open Swift 3 design topics

On Tue, Jun 28, 2016 at 10:03 PM, David Waite <da...@alkaline-solutions.com> wrote: > > On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote: > > On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution > <

Re: [swift-evolution] [Draft] UnsafeRawPointer API

On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick wrote: > >> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko wrote: >> >> Hi Andy, >> >> Everything is clear now, thank you! >> >> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote: >>>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Hi Andy, Everything is clear now, thank you! On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote: > Initializing via a typed pointer, in addition to changing the temporal memory > state, also imposes a type on the allocated memory for the entire lifetime of > the memory

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Hi Andy, Thank you for the proposal! A few comments from me. - In the "Custom memory allocation section" you write: > Note: The same allocated raw memory cannot be used both for this custom > memory allocation case and for the C buffer case above because the C buffer > requries that the

Re: [swift-evolution] [Pitch] Remove type inference for associated types

On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution wrote: > Hello all, > > Per Chris Lattner's list of open Swift 3 design topics > (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put > together a proposal for removing type

Re: [swift-evolution] Shorthand unwrap proposal

On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution wrote: > So if the function I run inside of the map has a return value of Void will > that still compile ? Yes. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j

Re: [swift-evolution] Shorthand unwrap proposal

On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution wrote: > I was wondering if people would be open to adding an unwrap method to the > Optional type, I already have a method like this which shortens code for > me. > > So this: > > let

Re: [swift-evolution] Revisiting SE-0041 Names

On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu wrote: > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution > wrote: >> >> >> > On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: >> > >> >> On Wed, Jun 22, 2016 at

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 7:42 PM, Matthew Johnson wrote: > > On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > > On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > wrote: > > Proposal: >

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 4:43 PM, Matthew Johnson wrote: > > On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > protocol _IntegerLiteralSyntax {} > enum Syntax { > typealias IntegerLiteral = _IntegerLiteralSyntax > } > > And used like this: > >

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote: > That's a really interesting idea. Is "Syntax" a placeholder, or is that the > intended name? It is the best name we could come up with, we are open to better suggestions. > Also, why an enum? Especially one without

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris <daveswee...@mac.com> wrote: > >> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evoluti

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution wrote: > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md > > Rejection: "The feedback on the proposal was generally positive about the >

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

On Wed, Jun 22, 2016 at 9:37 AM, Kenny Leung via swift-evolution wrote: > Hi All. > > In the spirit of Chris’ focus on Swift 3 message… > > I’ve been working on calling C code that takes “const char * const *” > arguments, and it ain’t easy, but that can be left for a

Re: [swift-evolution] [Pitch] remove(at: Set)

On Sat, Jun 18, 2016 at 10:59 PM, Karl wrote: > What exactly are the guarantees for index safety across mutations? Both > Collection and Indexable stop short of making any kind of guarantees about > what happens to indexes after you mutate. For example, popFirst() has the >

Re: [swift-evolution] [Pitch] remove(at: Set)

On Sat, Jun 18, 2016 at 9:09 PM, Karl via swift-evolution wrote: > So like most good pitches, this one comes about because of a bug I recently > fixed which seems common and subtle enough that I think it would be nice to > include in the standard library. > > Removing

Re: [swift-evolution] [Discussion] Type hierarchy translation consistency

On Sun, Jun 12, 2016 at 3:33 AM, Adrian Zubarev via swift-evolution wrote: > Just looked up the current implementation of this: > > extension String { > /// The index type for subscripting a string. > public typealias Index = CharacterView.Index > > /// A type

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On Sun, May 29, 2016 at 11:23 PM, Brent Royal-Gordon via swift-evolution wrote: > There are *very* few conformances to Streamable in the standard library—just > Character, String, and UnicodeScalar. I think that Streamable is for data > that can be *directly* written

Re: [swift-evolution] [Pitch] Remove associated type inference

On Wed, May 25, 2016 at 3:42 PM, Leonardo Pessoa <m...@lmpessoa.com> wrote: > On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Wed, May 25, 2016 at 2:52 PM, David Hart <da...@hartbit.com> wrote: &g

Re: [swift-evolution] [Pitch] Remove associated type inference

On Wed, May 25, 2016 at 2:52 PM, David Hart wrote: > >> On 25 May 2016, at 23:47, Dmitri Gribenko wrote: >> >> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution >> wrote: >>> Impact on Existing Code >>> >>> This is

Re: [swift-evolution] [Pitch] Remove associated type inference

On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution wrote: > Impact on Existing Code > > This is a breaking change that will require conforming types which relied on > the inference, including in the Standard Library, to explicitly declare > associated

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

I like the direction about creating a unified syntax for current implementation of existentials and future generalized existentials. I am concerned about the chosen syntax though, I don't think it reads right. I read Any as a union type. var x1: Any // OK, 'x1' can have any dynamic type.

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

On Sat, May 14, 2016 at 7:45 AM, Daniel Steinberg via swift-evolution wrote: > I appreciate your rework on this - I still don’t understand one thing and > disagree with a second: > > (1) I don’t understand what the word “Custom” adds to > CustomStringRepresentable and

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

On Fri, May 6, 2016 at 2:24 AM, Morten Bek Ditlevsen via swift-evolution wrote: > How does that sound? Is it completely irrational to allow the use of Strings > as > the intermediary representation of float literals? > I think that it makes good sense, since it allows

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

On Fri, May 6, 2016 at 12:53 AM, Nate Cook wrote: > That brings up the question of which protocol to add the requirement to? > Without a MutableBidirectionalProtocol (which we don't want, right?), we'd > need to add it to MutableCollection. While a mutating reverse() is

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

On Thu, May 5, 2016 at 5:11 PM, Nate Cook wrote: > Thanks for the feedback, Dmitri , 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

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

On Thu, May 5, 2016 at 3:27 AM, Gwendal Roué wrote: >>> I quite expect being able to throw out of a @noescape(once) block. Maybe >>> the sentence "it must not be executed on any path that throws" should be >>> removed from the proposal, should it have the implications

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

On Wed, May 4, 2016 at 2:24 AM, Gwendal Roué wrote: > >> Le 4 mai 2016 à 08:28, Pyry Jahkola via swift-evolution >> a écrit : >> >> Here's my review of "SE-0073: Marking closures as executing exactly once". >> >>> What is your evaluation of

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, May 2, 2016 at 3:08 PM, Karl via swift-evolution wrote: > So, just confirming that the following is going to change: > > — > var string= "test" > let origLen = 4 > let indexOne = string.startIndex > > string.appendContentsOf("ANOTHERTEST") > > let

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

On Fri, Apr 29, 2016 at 4:02 AM, David Hart wrote: > But Collection has to have an extension which explicitly mentions > IndexingIterator: > > extension Collection where Iterator == IndexingIterator { > /// Returns an iterator over the elements of the collection. >

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

On Fri, Apr 29, 2016 at 1:50 AM, David Hart wrote: > Hi Dimitri, > > Excuse me if I’m being dumb. I saw those example but I don’t understand > their use. > > If I define a custom Collection, I still have the be explicit in the types I > use where associated types are expected.

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

On Fri, Apr 29, 2016 at 12:25 AM, David Hart via swift-evolution wrote: > I’ve taken some time to digest the current feedback and I’ve changed my mind. > The syntax for adding constraints to a sub-protocol in the protocol’s > definition where clause is starting to

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

On Mon, Apr 25, 2016 at 8:28 PM, Douglas Gregor via swift-evolution wrote: > Did you consider an alternate syntax that puts the where clause outside the > braces, e.g., > > protocol R : Q where AssocType : P { > // … > } To me this reads like declaring a conditional

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

On Sun, Apr 24, 2016 at 1:34 PM, David Hart via swift-evolution wrote: > Currently, associated type declarations can only express simple inheritance > constraints and not the more sophisticated constraints available to generic > types with the where expression. Some

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Sun, Apr 17, 2016 at 11:14 PM, Thorsten Seitz wrote: > Preventing indices of one collection being used by another collection can be > done by using path dependent types like in Scala. > > Then 'i' would have type a.Index (where 'a' is the instance!) and therefore > b[i]

Re: [swift-evolution] [Draft] Expanded min/max algorithms

On Sat, Apr 16, 2016 at 11:50 PM, Taras Zakharko via swift-evolution wrote: > Hi Nate, > > I think this is a very useful addition! I also had a related proposal few > days ago: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html > > I

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf <s...@quanttec.com> wrote: > On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: >> >> Not even to mention that >> indices are valid only in context of a particular collection instance, >> so in this model yo

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Tue, Apr 12, 2016 at 4:27 AM, Brent Royal-Gordon wrote: >>> (On the other hand, it might be that I'm conceiving of the purpose of >>> `limitedBy` differently from you—I think of it as a safety measure, but you >>> may be thinking of it specifically as an automatic

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > (On the other hand, it might be that I'm conceiving of the purpose of > `limitedBy` differently from you—I think of it as a safety measure, but you > may be thinking of it specifically as

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > So, imagine that we have a type like this in the standard library: > > /// Represents a pre-validated index. A pre-validated index received > from a given collection is >

Re: [swift-evolution] [Proposal]Make .map return the calling collection type

On Tue, Apr 12, 2016 at 1:55 AM, Yogev Sitton via swift-evolution wrote: > Map is great for transforming an array of objects - it is very useful and I > use it a lot. > I would love to use Map with Dictionaries and other collections as well. > > As an example - let’s

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote: > Hi, > > On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué > wrote: >> Will it still be possible with the new protocol and types? Especially, how >> to I generate "BETWEEN 0 AND 17" from 0..<18

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Hi, On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué wrote: > Will it still be possible with the new protocol and types? Especially, how to > I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection > that gives me the predecessor of 18? You would

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

On Fri, Apr 8, 2016 at 3:49 AM, Vladimir.S wrote: > > > On 07.04.2016 21:43, Dmitri Gribenko wrote: >> >> There would be no need to. Collection will have a .successor(of:) >> method that returns the next index after the given one. >> > > I see. Thank you for letting know about

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

On Thu, Apr 7, 2016 at 11:27 AM, Vladimir.S wrote: > OK, thank you for the clarification Dmitri. > If these methods are going away - no possible problems :-) > Will we have some kind of .next() method for integers in new indexing model > and in Swift 3.0 in general? There would

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via swift-evolution wrote: > But. .successor() .predecessor() methods for Int values do not follow these > rules for overflow situations. I.e. : > let i : Int8 = Int8.max > let k : Int8 = i.successor() > - is OK for current

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

On Mon, Mar 21, 2016 at 4:14 PM, Jordan Rose via swift-evolution wrote: > I've recorded everyone's feedback so far (mostly on the UnsafeBufferPointer > issue) and opened a pull request: > https://github.com/apple/swift-evolution/pull/219. Thanks, Jordan! I have a

Re: [swift-evolution] Draft of proposal for autoreleasepool signature change

On Mon, Mar 21, 2016 at 10:34 PM, Timothy Wood via swift-evolution wrote: > > I think I’ve captured the feedback and conversation so far. Please let me > know if I’ve missed anything or if there are further concerns or ideas for > improvement. Hi Timothy, Your

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

On Tue, Mar 15, 2016 at 9:31 AM, Erica Sadun wrote: > I would like to update my draft proposal to introduce a test for debug > configurations using a public function > rather than a build configuration test. > > * Would the stdlib team be open to that? No objections from

Re: [swift-evolution] Add an ifPresent function to Optional

On Mon, Mar 14, 2016 at 5:51 PM, <daveswee...@mac.com> wrote: > > On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote: > > Optional.map returns an Optional. > > Array.map returns an Array. > Set.map returns an A

Re: [swift-evolution] Should all GeneratorTypes also be SequenceTypes?

On Mon, Mar 14, 2016 at 4:42 PM, Haravikk via swift-evolution wrote: > There are quite a lot of generator implementations that also implement > SequenceType (since it’s as simple as returning self). Indeed, the > AnyGenerator type conforms to SequenceType, allowing

Re: [swift-evolution] Add an ifPresent function to Optional

On Mon, Mar 14, 2016 at 3:44 PM, Erica Sadun wrote: >> No. My argument is that map on collections and on optionals are two >> completely different things. They unify on a level that does not >> exist in Swift (higher-kinded types). We could name Optional.map() >>

Re: [swift-evolution] Add an ifPresent function to Optional

On Fri, Mar 11, 2016 at 7:17 PM, Howard Lovatt via swift-evolution wrote: > @Dave, Yes, CollectionType would be better than SequenceType. We already considered doing this a long time ago, and we decided against it. 1. `for x in y {}` would start working everywhere

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > I agree in principle that it would be great if String could enforce that > it's always valid. > > But unfortunately, in practice, there's no way to do that without making > it expensive to

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 2:01 PM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > As I know SequenceType should have behaved as immutable structure and it > provides method to get a mutable GeneratorType which generates value from > start of sequence. Sequences are not

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 3:04 PM, Susan Cheng wrote: > yes for sequences are not immutable. I get confused. > > no for sequences should be definition of lists of values. Just like > Fibonacci sequence, we can calculate the values form the start of the > Fibonacci sequence

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 3:36 PM, Susan Cheng wrote: > I don't think so. > > As we don't say "Fibonacci collection", we know Fibonacci numbers are in > order. But we can't tell the number immediately if I asked a specific index > of Fibonacci sequence. The only way is

  1   2   >