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

> On Jan 13, 2018, at 1:40 PM, Erica Sadun <er...@ericasadun.com> wrote: > > > >> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote: >> If we can't do this, I think we should call it someth

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 11, 2018, at 4:21 PM, Paul Cantrell wrote: > > This raises a question related to Chris’s: what is the utility of having Limb > conform to a protocol instead of just providing allValues ad hoc? Does > CaseEnumerable / ValueEnumerable serve any purpose other than

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Jan 10, 2018, at 12:15 AM, Martin Waitz <t...@admingilde.org> wrote: > > Hello Brent, > >> Am 10.01.2018 um 06:15 schrieb Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org>: >> >> For what it's worth, I *might* intr

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution > wrote: > > I continue to have concerns about this proposal, and I'm gravely and very > bitterly disappointed that the concerns have not even been acknowledged in > the Alternatives section, which is in

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

> On Jan 8, 2018, at 3:23 PM, Gregg Wonderly via swift-evolution > wrote: > > But why wouldn’t the key also be available so that you might be able to have > selective handling of first vs last for each key? Having only the values allows you to do some nice

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution > wrote: > > - FWIW I can't actually think of a use case for using this with `if case` or > anything else. I'm not against it, but I don't know why you would ever do it, > just like I don't know why you

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

> On Jan 9, 2018, at 9:04 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > > The problem is that this isn't currently expressible in the type system. If > we can, I would actually support including some kind of unprincipled private > hac

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Jan 8, 2018, at 11:02 AM, Robert Widmann via swift-evolution > wrote: > > As you note, integral types and Bool and some enums that fall outside the > scope of the synthesis requirements fit this mold quite nicely. We do not > include them in the proposal

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

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution > wrote: > > I’m canvassing for opinions on what it ought to be called. Some suggestions > so far: > > - `AssociationCollection`: Following the term of art from some other > languages. Slightly

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 3, 2018, at 10:02 AM, Dave DeLong via swift-evolution > wrote: > > 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on > externally-linked modules Naming is serious business, Dave. Let it go. *ducks* -- Brent Royal-Gordon

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

> On Dec 21, 2017, at 10:33 AM, Jordan Rose via swift-evolution > wrote: > > The main blocker was that such a case becomes untestable (see also "Testing > invalid cases"). You can always make it testable through appropriate factoring—for example, have the `future`

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 10:02 AM, Dave DeLong via swift-evolution > wrote: > > I would love to see some sort of formal API versioning that we could do > instead in libraries, along with easy runtime support for checking the linked > version of libraries, making it

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution > wrote: > > My one bikeshedding issue here is the name @abiPublic, which smells too much > like fileprivate in my subjective opinion. A more concrete objection here is > the very much non-ideal

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > > • What is your evaluation of the proposal? I am pleased with the broad strokes of this design. I have quibbles with three areas: 1. The `@exhaustive` attribute may be confusing

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution > wrote: > >> The expectation is that switches over non-exhaustive enums are uncommon. > > > Basically every time I interact with an enum, I switch over it, to make sure > I don’t forget

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

> On Dec 19, 2017, at 8:56 AM, John McCall wrote: > > Therefore, SE-0187 is accepted, with the revision that the new name be > Sequence.compactMap(_:), and with the agreement that we will add > Sequence.compact() when it is possible to do so. I like `compact` as the basis

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > wrote: > Just wanted to give my 2¢ > > ¢ > I don’t like empty protocols—they feel like

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution > wrote: > > That said, I am not sure that this proposal should give any pretense of being > suitable for cryptographic use. On implementation, the code will not have > been audited for that purpose,

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: > > We’ve had a lot of discussions over the years about how to balance simplicity > vs power, implicitness vs explicitness, intentionality vs accidental > behavior, etc. For example, in very early discussions about Swift

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution > wrote: > > Just to talk to myself a bit here, but I’ve come to realize that the right > design really is to have a simple empty marker protocol like this: If you're reaching this point. why have a

Re: [swift-evolution] [Pitch] Raw mode string literals

> On Nov 23, 2017, at 11:15 AM, Chris Lattner via swift-evolution > wrote: > > Until we figure out that path forward for regex’s, I think they aren’t the > right motivation for this proposal. 1. Even in our shining pattern matching future—a future which I, for one,

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution > > wrote: > > What if you write ‘let fn = obj.method’? Since Ruby doesn't distinguish between properties and methods, I would write the `subscript(dynamicProperty:)`

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution > wrote: > >> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution >> > wrote: >> > > >> Moreover, Ruby allows classes to have

Re: [swift-evolution] proposal 0143-conditional-conformances

> On Nov 19, 2017, at 4:11 PM, Matt Whiteside via swift-evolution > wrote: > > Bosses at Apple: if you are reading this, please allow the swift compiler > team the bandwidth to work on this. Thanks. They are. If you take a look at recent pull requests at

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution > wrote: > > But actually, Int.random followed by % is the much bigger issue and a very > good cautionary tale for why T.random is not a good idea. Swift should help > users do the correct thing, and

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 16, 2017, at 10:08 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > > So, let me sketch a vague idea of how this might work. This is definitely not > fully baked, but it might give you an idea. Looking at this again, I realize I a

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 16, 2017, at 1:44 PM, Paul Cantrell <p...@bustoutsolutions.com> wrote: > >> On Nov 16, 2017, at 12:00 AM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> * Ruby an

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 15, 2017, at 4:36 PM, Greg Parker via swift-evolution > wrote: > > "compactMap" is okay if "compact" is added. Is "compact" a common enough > operation in practice to pull its own weight? Lines containing code like `flatMap { $0 }`—which could be compacting

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution > wrote: > > extension PyVal { > subscript(dynamicMember member: String) -> PyVal { > get { > let result = PyObject_GetAttrString(borrowedPyObject, member)! > return PyRef(owned:

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 15, 2017, at 8:35 PM, Paul Cantrell via swift-evolution > wrote: > > Q: Is there any special handling for that member name string — to handle ruby > method names like `blank?`, for example? > > A: This should be the job of a language-specific interop layer.

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu wrote: > > 1. It must be possible to easily access the count of values, and to access > any particular value using contiguous `Int` indices. This could be achieved > either by directly accessing elements in the list of values

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Nov 12, 2017, at 10:16 AM, Xiaodi Wu wrote: > > On Sun, Nov 12, 2017 at 4:54 AM, Brent Royal-Gordon > wrote: >> On Nov 10, 2017, at 11:01 PM, Xiaodi Wu > >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 13, 2017, at 10:11 AM, Shawn Erickson via swift-evolution > wrote: > > > On Mon, Nov 13, 2017 at 10:02 AM C. Keith Ray via swift-evolution > > wrote: > > You said "compact" removes nil values, so

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution > wrote: > > Hello evolution folks, > > After the positive feedback on the idea of improving capturing semantics of > local functions, Alex Lynch and I worked on a proposal. Please let us know if > you

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 9:29 PM, Paul Cantrell via swift-evolution > wrote: > > The problem in the Doodads example is that the name flatMap is used to > identify two distinct intents: concatenating arrays and filtering nils. One > can argue that those two operations

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > wrote: > > Opening up the compiler architecture to make custom importers easier to write > is a great solution to a ton of problems, including yours I think, without > adding complexity to the core

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Nov 10, 2017, at 11:01 PM, Xiaodi Wu wrote: > > Nit: if you want to call it `ValueEnumerable`, then this should be > `DefaultValueCollection`. I used `DefaultCaseCollection` because, although the protocol can work with any type to return its values, this type can

Re: [swift-evolution] JSONEncoder: Key strategies

> On Nov 9, 2017, at 10:00 AM, Itai Ferber wrote: > > Hi Brent, > > Perhaps the wording would be better phrased as "boundary from > non-uppercase-character to uppercase-character", i.e. numbers and Emoji are > treated the same as lowercase characters and are included in the

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> Personally I like the flexibility provided by the associatedtype, but I also > recognize it won't be incredibly useful for enums — more so if we wanted to > provide e.g. UInt8.allValues, whose ideal implementation might be "return > 0...UInt8.max". So I could see allowing allValues to be any

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Leaving the "should we do it at all" question aside… > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > We propose introducing this protocol to the standard library: > > protocol DynamicCallable { > associatedtype DynamicCallableArgument

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

> On Nov 9, 2017, at 4:29 AM, Xiaodi Wu wrote: > > Why not? Specifically, why shouldn't we require `Hashable` conformance on > indices? Adding it would require changes to conforming types, sure, but > indices are already required to be `Equatable`, and `Hashable`

Re: [swift-evolution] JSONEncoder: Key strategies

> On Nov 6, 2017, at 12:54 PM, Tony Parker via swift-evolution > wrote: > > Converting from camel case to snake case: > > 1. Splits words at the boundary of lower-case to upper-case > 2. Inserts `_` between words > 3. Lowercases the entire string > 4. Preserves

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Oct 31, 2017, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > Since you bring it up, Python exceptions will be annoying - As with other > languages, Python can throw from an arbitrary expression. Modeling > everything as throws in Swift would be

Re: [swift-evolution] Adding Result to the Standard Library

> On Nov 9, 2017, at 3:16 AM, Gwendal Roué via swift-evolution > wrote: > > I wish that the Swift-Evolution discussion around typed / untyped throws > would avoid three traps: > > - a bloodshed between pro and anti typed-throws > - a pro-typed-throws echo chamber

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

> > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md > > • What is your evaluation of the proposal? This all seems very sensible, but here's my big question: AnyIndex, which type erases any index type at run-time, would not be

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 2, 2017, at 7:05 PM, Xiaodi Wu via swift-evolution > wrote: > > Firstly, because for the proposed use case it's not a "default" parameter in > that it's not overridable: you can't actually pass another argument. Sure you can. Remember, you can call an

Re: [swift-evolution] Abstract methods

> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution > wrote: > > Swift architectures use much less inheritance (and class types) in general > than equivalent c++ architectures. personally i have never been in a > situation where i didn’t need a pure

[swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

During the Swift 3 cycle, I proposed SE-0132, "Rationalizing Sequence end-operation names". It was rejected because it needed revision and there was no time to do so. Since then, part of the proposal—partial ranges and the `RangeExpression` slicing protocol—has been adopted in SE-0172,

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution > wrote: > > This idea was discussed long ago and the present design was selected. But this design was discussed in the proposal as a "future direction", because @discardableResult was chosen partially

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution > wrote: > > That is reflected in the fact that over half the methods in the main Sequence > definition* make no sense and are not well-defined unless there is a > well-defined order to the sequence

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 11, 2017, at 10:21 AM, Cory Benfield via swift-evolution > wrote: > > This user will never swap away from the default, so the question is which > failure mode is preferable. I’d say it seems pretty obvious that “my program > is slow” is a better failure

Re: [swift-evolution] [Proposal] Random Unification

On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution wrote: > > IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array > (RandomAccessSequence?), they should just be for convenience and with a sane > default RNG*, and users that need more

Re: [swift-evolution] await keyword "scope"

> On Sep 18, 2017, at 9:47 AM, Adam Kemp wrote: > >> Would it be possible to actually fix this? That is, make the code covered by >> the `await` evaluate synchronous subexpressions first, such that the code >> sample above is equivalent to this? >> >> @IBAction func

Re: [swift-evolution] await keyword "scope"

> On Sep 12, 2017, at 12:48 PM, Adam Kemp via swift-evolution > wrote: > > @IBAction func buttonDidClick(sender:AnyObject) { > beginAsync { > let image = await processImage(downloadImage(), resize: > self.resizeSwitch.isOn) > displayImage(image) >

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 13, 2017, at 4:21 AM, Gwendal Roué via swift-evolution > wrote: > >>> If I take on my free time exposing issues, it's because I hope that maybe >>> some reader will consider them with proper attention, then maybe agree that >>> there is an issue worth

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 12, 2017, at 6:30 PM, Jordan Rose wrote: > > It gets a little tricky if layout matters—Optional fits exactly in > a single word-sized value, but Optional does not on > Apple platforms—but that just means it should be opt-in or tied to >

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution > wrote: > > - I’d love to see several of the most common random kinds supported, and I > agree it would be nice (but not required IMO) for the default to be > cryptographically secure. I would be

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 9, 2017, at 12:03 PM, Taylor Swift via swift-evolution > wrote: > > I would argue that anyone doing cryptography probably already knows how > important RNG selection is and can be expected to look for a specialized > cryptographically secure RNG. I doubt

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 8, 2017, at 6:03 PM, Xiaodi Wu via swift-evolution > wrote: > > For any open protocol (i.e., a protocol for which the universe of possible > conforming types cannot be enumerated a priori by the protocol designer) > worthy of being a protocol by the Swift

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution > wrote: > > Here, people just want an array of all cases. Give them an array of all > cases. When it's not possible (i.e., in the case of cases with associated > values), don't do it. I agree it should

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution > wrote: > > What if we did it with something like this: > > protocol RandomGenerator { > associated type T: Numeric // Since numeric types are the only kinds > where we could get a random

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution > wrote: > > I've taken everyone's feedback into consideration and written this up as a > proposal: >

Re: [swift-evolution] Contextualizing async coroutines

> On Sep 2, 2017, at 2:56 AM, Pierre Habouzit wrote: > >> `onResume` hooks seem like a really good way to, essentially, allow >> arbitrary concurrency primitives to be passed into `async` functions. My >> main question is, if we have it, why do we need coroutine contexts?

Re: [swift-evolution] Contextualizing async coroutines

> On Aug 31, 2017, at 11:35 AM, Joe Groff via swift-evolution > wrote: > > # Coroutine context > > # `onResume` hooks `onResume` hooks seem like a really good way to, essentially, allow arbitrary concurrency primitives to be passed into `async` functions. My main

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 31, 2017, at 5:51 PM, André “Zephyz” Videla > wrote: > > That is exactly what I argue should be avoided. When you see `+` you don’t > expect it to throw. Perhaps not, but the language makes you mark the expression with `try` to make that fact clear. And your

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 25, 2017, at 10:12 PM, Howard Lovatt via swift-evolution > wrote: > > I think we would be better off with a future type rather than async/await > since they can offer timeout, cancel, and control over which thread execution > occurs on. async/await is a

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 22, 2017, at 9:32 AM, Joe Groff via swift-evolution > wrote: > >>> async as a subtype of throws instead of orthogonal to it >>> >>> I’ve been thinking a lot about this since the proposal came out and I see a >>> few serious disadvantages at making async a

Re: [swift-evolution] Is there a simple way to go from Codable to Any and vice versa?

> On Aug 22, 2017, at 12:32 PM, Youming Lin via swift-evolution > wrote: > > Hi all > > With Swift 4 Codable support, we can now do the following conversions: > Codable <-> Data using JSONEncoder/JSONDecoder > Any <-> Data using JSONSerialization > > Not sure if I

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 21, 2017, at 10:47 PM, Jonathan Hull via swift-evolution > wrote: > > I am finding that I DO NOT understand beginAsync. At first I thought it was > the async/await version of 'do{}’, but as others are giving examples which > use it in different ways, I

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 21, 2017, at 12:41 PM, Wallacy via swift-evolution > wrote: > > Based on these same concerns, how to do this using async/await ? > > func process() -> Void) { > loadWebResource("bigData.txt") { dataResource in > // > } >

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > wrote: > > The only practical merit of typed throws I have ever seen someone demonstrate > is that it would let them use contextual lookup in a throw or catch. Let me take this in a slightly

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 19, 2017, at 1:29 PM, Michel Fortin via swift-evolution > wrote: > > I'm not actually that interested in the meaning of value semantics here. I'm > debating the appropriateness of determining whether something can be done in > another thread based on the

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: > > Regardless of which approach we take, it feels like something that needs to > be implicit for structs and enums where value semantics is trivially provable > by way of transitivity. When that is not the case we

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 19, 2017, at 3:23 AM, Georgios Moschovitis via swift-evolution > wrote: > > I am wondering, am I the only one that *strongly* prefers `yield` over > `await`? > > Superficially, `await` seems like the standard term, but given the fact that > the proposal is

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 19, 2017, at 2:25 AM, Thomas wrote: > >> I think we need to be a little careful here—the mere fact that a message >> returns `Void` doesn't mean the caller shouldn't wait until it's done to >> continue. For instance: >> >> listActor.delete(at: index)

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 18, 2017, at 12:35 PM, Chris Lattner wrote: > >> (Also, I notice that a fire-and-forget message can be thought of as an >> `async` method returning `Never`, even though the computation *does* >> terminate eventually. I'm not sure how to handle that, though) > >

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 17, 2017, at 11:59 PM, Félix Cloutier via swift-evolution > wrote: > > The purpose of `beginAsync` is to start an `async` function while firewalling > against the propagation of the `async` keyword to the caller. `beginAsync` > does not return a value. By

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 17, 2017, at 11:34 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > > * I haven't yet read the rest of the thread—this email is already long enough. The detailed async/await proposal cleared up a few bits for me—in particular, I cle

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 10, 2017, at 3:40 AM, Haravikk via swift-evolution > wrote: > > This is not the same as a default protocol implementation Actually, I could easily imagine that a future version of Swift with macro support might do this with a default protocol

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 8, 2017, at 3:28 PM, Jordan Rose via swift-evolution > wrote: > > Let's now flip this to the other side of the equation. I've been talking > about us disallowing exhaustive switching, i.e. "if the enum might grow new > cases you must have a 'default' in a

Re: [swift-evolution] Pitch: Improved Swift pointers

> On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution > wrote: > > What about `value:`? > > `ptr.initialize(value: value)` > `ptr.initialize(value: value, count: 13)` > `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)` Doesn't read as a

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution > wrote: > > Upfront costs *will* be higher. Not only do you have to believe that a change > is good, you must develop a working group that includes coders to create a > prototype without any guarantee

[swift-evolution] ExpressibleByStringInterpolation

I had a proposal for replacing/reintroducing `ExpressibleByStringInterpolation` (which is currently deprecated pending a redesign), but it landed too late in the Swift 4 cycle to be considered. The PR is here: https://github.com/apple/swift-evolution/pull/659 I think it squares up relatively

Re: [swift-evolution] Swift's 'observe()' doesn't work for key paths with optionals?

> On Jul 22, 2017, at 12:12 AM, William Shipley via swift-evolution > wrote: > > submodelObservation = observe(\.controller.submodel) { object, change > in > // code > } > > > @objc dynamic internal var controller: Controller? > > in the

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On Jul 7, 2017, at 4:27 PM, Dave Abrahams wrote: > > Yes, that's a lot of extra syntax. But again, you've used an > abbreviated, single identifier for the property and a > short, non-descriptive identifier for the array. Let's make this a > fair/realistic comparison: >

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On Jul 6, 2017, at 9:13 AM, Dave Abrahams wrote: > > I'm not sure what you're objecting to about this. Is it the very > appearance of curly braces? I went to bed thinking that maybe I should have explained that better, and I guess I was right. ;^) Here's why I think we

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On Jul 5, 2017, at 2:23 PM, Dave Abrahams via swift-evolution > wrote: > > I am not convinced this syntactic sugar is worth complicating the > language or library for, For what it's worth, I think it is *totally* worth complicating the language or library. The

Re: [swift-evolution] [Pitch] Contextual variables

> On Jun 28, 2017, at 5:33 AM, Dimitri Racordon via swift-evolution > wrote: > > Using our contextual variables, one could rewrite our motivational example as > follows: > > class Interpreter: Visitor { > func visit(_ node: BinExpr) { > let lhs, rhs :

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

> On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution > wrote: > > Given a type MyType, how can I get a type-alias to the type’s protocols? If > MyType conforms to Protocol1 and Protocol2, I would want something like > > typealias MyProtocol =

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 30, 2017, at 5:38 AM, Matthew Johnson wrote: > >> 3. If we later change `throw` from being a statement to being a >> `Never`-returning expression, you could use `throw` on the right-hand side >> of `??`. > > What do you have in mind here? I don't recall any

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution > wrote: > > Using an operator to provide feedback on the context of a failed unwrap has > become a commonly implemented approach in the Swift developer Community. What > are your thoughts about

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution > wrote: > > How do you express the idea that, when you add values of disparate types T > and U, the result should be of the type with greater precision? You need to > be able to spell this somehow. To

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 10:28 AM, Chris Lattner via swift-evolution > wrote: > > My belief on this is that it is a legacy Swift 1 type system capability that > no one uses. I have no data to show that though. Tangential and perhaps a terrible idea, but: It's 2017.

Re: [swift-evolution] [Meta] WWDC week

> On Jun 5, 2017, at 8:53 PM, Brent Royal-Gordon > wrote: > > How does Friday sound to people? Based on a couple of Twitter responses, it > seems to be pretty open, and it has the advantage that nobody's gonna have a > talk or event the

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution > wrote: > > Well please no: > > 
> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead use destructuring sugar pitched by Chris Lattner on the other thread: > > let fn2: ((Int, Int)) ->

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution > wrote: >> >> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >> a écrit : >> >> Here, container is stored as a `let` value, and uses reference semantics, >>

Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution > wrote: > > Static-sized arrays should not be shoved into being a tuple with funny > settings; that introduces subtleties into the tuple concept only because of > jammed-in array support. The fact 3

[swift-evolution] [Pitch] UnsafePointer.advanced(to:)

It won't happen for Swift 4, but I think we should eventually have APIs like: extension UnsafePointer { func advanced(to keyPath: KeyPath) -> UnsafePointer? } If keyPath referred to a stored property directly inside the value, this would return a pointer to that property. If

Re: [swift-evolution] [Meta] WWDC week

> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon > wrote: > > I'm going to be in San Jose during WWDC next week, and I'm assuming I won't > be the only one. Are there any swift-evolution meetings or events planned? > Personally, I'd love to put some faces to names

Re: [swift-evolution] Pitch: String Index Overhaul

> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution > wrote: > > A property and an intializer will be added to `String.Index`, exposing > the offset of the index in code units (currently only UTF-16) from the > beginning of the string: > > ```swift >

  1   2   3   4   5   6   7   8   9   >