[swift-evolution] [Pitch] String prefix operator

Motivational example: var urlString = self.urlString if urlString.hasPrefix("//") { urlString = "http:" + urlString // urlString needs to be typed twice } While there is currently an easy way to append string using +=, there is no shortcut for prefixing a string. What I propose is adding

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

> On Jun 17, 2016, at 1:12 AM, Brent Royal-Gordon > wrote: > >> - func descriptionWithDefaultValue(_ defaultValue: String = "nil") -> >> String - which would return either the description of the value, or >> `defaultValue`. > > This is the same as myOptional?.description ?? defaultValue

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > -1, for the same reasons stated on the thread. These are neither > guaranteed to be mutating or non-mutating until you get to Collection. > Changing map() to mapped() would be lying to the developer some of the > time about the mutability of the interface. > -DW Actually the -ed/-ing suffix i

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

> On Jun 16, 2016, at 11:30 PM, William Shipley wrote: > >> private lazy var floorGeometryAndMaterialBacking: >> FloorPlatonicGeometryAndMaterial? = >> try! >> FloorPlatonicGeometryAndMaterial(modelDirectory: self.modelDirectoryURL) > > Oddly, the “self.” ma

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> The 'reduce()' at its core take an array of element and reduce it to single > element (could be of a different type) as such it cannot ever be mutating (if > one really want it, one could reduce an array to the same array but it is not > the goal of the function). For this one it sound to me n

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Isn't the rule only for the case where you can have a mutating and non-mutating variant? The 'reduce()' at its core take an array of element and reduce it to single element (could be of a different type) as such it cannot ever be mutating (if one really want it, one could reduce an array to the

Re: [swift-evolution] Compiler Warning on Unextended Classes

It seems to me that such a linter would need to scan the entire module to determine if a class is subclassed, provided that it is internal. My understanding of linters is that they typically don't do static analysis of this sort, they are more targeted at local source or AST analysis. Whole module

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> Le 16 juin 2016 à 11:29, Charlie Monroe via swift-evolution > a écrit : > > Have you considered just #if os(mac)? I mean the fact that you're testing > against "OS" is already expressed. I know it goes against the other values > (watchOS, tvOS), but I'd personally drop those as well in favo

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

+1 I was definitely surprised when these weren't changed with the other methods. They will still be easily found with the new names, and the current inconsistency makes the -ed/-ing rule much harder to grok / trust (especially considering how often these are used). I do understand David Waite

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

> - func descriptionWithDefaultValue(_ defaultValue: String = "nil") -> > String - which would return either the description of the value, or > `defaultValue`. This is the same as myOptional?.description ?? defaultValue, isn't it? So do we need it? -- Brent Royal-Gordon Architechies __

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

-1 The Term of Art argument is very strong with these functions. I prefer them as-is. > On 16 Jun 2016, at 12:51, Patrick Pijnappel via swift-evolution > wrote: > > Due to considerably support on this thread >

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

Inline for ease of read: CoreMotion CMMotionActivityManager Two modifications here: Remove the starting suffix as it only really pertains to the first argument. Rename the queue label to on to reduce the

[swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

I’ve only started using the transformed APIs from Apple frameworks that were auto-modified and I’ve found a few cases where the automatic translation doesn’t seem to follow the Swift Design Guidelines. I don’t know how much can be fixed manually, but if it can, it would be forth congregating as

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> map => mapped > flatMap => flatMapped > filter=> filtered > reduce=> reduced You posted before I finished responding to this on the other thread, so I guess I'll do it here. You're right that renaming these operations wouldn't be terrible. But I think they're easily distingui

Re: [swift-evolution] Bitshift operators

> A proposal is imminent. Great—thanks for the update. -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

-1 for the aforementioned reasons by David Waite and T.J. Usiyan. On Thu, Jun 16, 2016 at 9:51 PM, Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Due to considerably support on this thread >

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

William Shipley wrote: > I may be missing something, but I don’t understand how to get the behavior > of dispatch_once() without a bunch more code in cases in which I was using > it to initialize “lazy-ish" instance variables. In Objective-C, the `dispatch_once_t` predicate *must* be a static or

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

> private lazy var floorGeometryAndMaterialBacking: > FloorPlatonicGeometryAndMaterial? = > try! > FloorPlatonicGeometryAndMaterial(modelDirectory: self.modelDirectoryURL) Oddly, the “self.” made all the difference in getting it to compile. I’m not clear why

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

-0.5 I find the "term of art" argument strong in this case, especially for map/filter/reduce. These functions are different than for example `sort` because there can’t be a general mutating method of `map`. A variable of type `[A]` can’t be mutated to hold a `[B]` which would be the result of

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Thinking on it more after that–admittedly–visceral reaction, the proposed changes would be an annoying break from the terms but would remain as discoverable via autocomplete and can still be found easily when searching. I'd like to amend my vote to 0. If it makes the methods/functions easier to rea

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

I've used something that is very similar to dispatch_once in Swift 2.2. It looks like this (taken from real code in a real application): public static let defaultMap: RAStaticMap = RAStaticMap.loadCountries() The function RAStaticMap.loadCountries() is actually private, and it is called exactly

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

no -1 I agree that the names of these methods are inconsistent in the abstract but they are established terms of art, in my opinion. On Thu, Jun 16, 2016 at 1:38 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > -1, for the same reasons stated on the thread. These are ne

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

-1, for the same reasons stated on the thread. These are neither guaranteed to be mutating or non-mutating until you get to Collection. Changing map() to mapped() would be lying to the developer some of the time about the mutability of the interface. -DW > On Jun 16, 2016, at 1:53 PM, Adrian Z

Re: [swift-evolution] Compiler Warning on Unextended Classes

I think that linters are the best way to handle this. It’s not really a code smell that should always be taken care of (which would indicate that the compiler should warn about it), and as such should be relegated to the linter. On Thu, Jun 16, 2016 at 10:08 AM Rehat Kathuria via swift-evolution <

Re: [swift-evolution] Compiler Warning on Unextended Classes

I think unextended classes shouldn't be a compiler warning. They even shouldn't be an optional linter warning. There is a class. It doesn't have subclasses because I may have not written them yet. The process of writing software has to be anticipated somehow. I have 2 options: 1) I write the su

Re: [swift-evolution] API Guidelines: dropFirst?

There seems to be a decent amount of support for revisiting these. I drafted a proposal here: [thread] On Thu, Jun 16, 2016 at 8:56 PM, Shawn Erickson wrote: > I agree the essence of the "terms of art" can

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

+1 very much for consistency. --  Adrian Zubarev Sent with Airmail Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution (swift-evolution@swift.org) schrieb: Due to considerably support on this thread, a draft proposal to revisit the core functional method exceptions to the -ed

[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Due to considerably support on this thread , a draft proposal to revisit the core functional method exceptions to the -ed/-ing rule. Online version: https://github.com/PatrickPijnappel/swift-evolution/blob/fun

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Sorry, didn't have time to actually submit the proposal, but it at least gave me some time to think it through a few more times. After reconsiderations, I suggest the following: - deprecation of interpolation of optionals. - extending the Optional type by: - var detailedDescription: Stri

Re: [swift-evolution] API Guidelines: dropFirst?

I agree the essence of the "terms of art" can still exist in the base name while applying the "ed/ing rule". I would vote to have these renamed to better align with Swift and less with the terms of art. -Shawn On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution < swift-evolutio

Re: [swift-evolution] [DRAFT] Enhancing the Platform Configuration Test Suite for Conditional Compilation Blocks

Regarding "Bitwidth describes the number of bits used to represent a number. This proposal introduces a bitwidth test with two options: 32 and 64."... I don't fully understand how this will work or in general how it will be used. - "used to represent a number"... What "number" (e.g. what type)

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

Hard to say without full code, but the following code compiles just fine in Xcode 8: class FloorPlatonicGeometryAndMaterial { init(modelDirectory: NSURL) throws { /// ... } } class PlatonicPieceOfFurniture { internal var modelDirectoryURL: URL

Re: [swift-evolution] Normalizing operator's types

Just checked with Swift 3.0 (Jun 6, 2016), func f(_ arg: (Int, Int)) -> Int { return arg.0 + arg.1 } // type : (Int, Int) -> Int This won't compile: f(4, 5) // returns 9 ERROR : extra argument in call This works as expected: f((4,56)) // returns 60 On 16.06.2016 21:08, J. Charles N. MBIADA

Re: [swift-evolution] Normalizing operator's types

-- J. Charles Le 16 juin 2016 à 15:57, Jeremy Pereira a écrit : On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution wrote: Hi Swift, Since the "removal" of curried function, I am looking for some elegant ways to work with partial functions (and reduce creation of closu

[swift-evolution] Removal of dispatch_once() in Swift 3?

I may be missing something, but I don’t understand how to get the behavior of dispatch_once() without a bunch more code in cases in which I was using it to initialize “lazy-ish" instance variables. public class PlatonicPieceOfFurniture { internal var modelDirectoryURL: URL /* … */

Re: [swift-evolution] API Guidelines: dropFirst?

> On Jun 16, 2016, at 11:40 AM, Patrick Pijnappel > wrote: > > Hmm, after some consideration I think we should reconsider renaming all of > the exceptions (map => mapped, filter => filtered, etc). > > The main reason to use a term of art is such that people already familiar > with the term w

Re: [swift-evolution] API Guidelines: dropFirst?

Hmm, after some consideration I think we should reconsider renaming all of the exceptions (map => mapped, filter => filtered, etc). The main reason to use a term of art is such that people already familiar with the term will immediately understand it. However as Jonathan points out, since the modi

Re: [swift-evolution] Compiler Warning on Unextended Classes

Agree with Sean that this shouldn’t apply to classes declared public; I also don’t think the "default by final” discussion ever came to a consensus. As for linters, my understanding of them is that they’re inclined to style-guides as opposed to architectural suggestions.The declaration of a clas

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> > On Jun 16, 2016, at 10:53 AM, Charlie Monroe > wrote: >> * the configuration test should not remain as #if os(OSX) because that's the >> wrong name > > Agreed. > >> * replacing OSX with macOS places an undue burden on existing code > > Since Swift 3.0 is a code-breaking change my guess i

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Ok, I guess we will wait for the core team (or perhaps Ilya) to return and advise then… Thanks, Jon > On Jun 16, 2016, at 7:33 AM, Robert Widmann wrote: > > That is for migration. It does not affect the semantics of private at any > level, it merely explains how we should go about the initia

Re: [swift-evolution] Compiler Warning on Unextended Classes

On Thu, Jun 16, 2016 at 11:39 AM, L. Mihalkovic via swift-evolution < swift-evolution@swift.org> wrote: > Likely a lint level feature, no? Agreed. Sounds like a linter feature. > > On Jun 16, 2016, at 6:27 PM, Sean Heber via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I would

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> On Jun 16, 2016, at 6:02 PM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 16, 2016, at 9:55 AM, David Waite > > wrote: >> >> (repost) >> >> Two comments: >> >> - I’ll specifically call out that I think treating this as an alias rather >> th

[swift-evolution] [DRAFT] Enhancing the Platform Configuration Test Suite for Conditional Compilation Blocks

This is an omnibus conditional compilation block proposal. It is built out of Swift Evolution community requests and discussions dating back on various threads to the genesis of the list. This draft does not include tests for debug conditions. That was pitched under separate cover using runtim

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> Am 16.06.2016 um 17:36 schrieb Paul Cantrell : > >> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Protocols are a mechanism for deriving types from each other whereas >> generics are a way to parameterize types. My point wa

Re: [swift-evolution] Compiler Warning on Unextended Classes

Likely a lint level feature, no? > On Jun 16, 2016, at 6:27 PM, Sean Heber via swift-evolution > wrote: > > I would think this would not apply to public classes. > > There has also been discussion in the past about making final the default - I > don’t remember if that ever resolved into some

Re: [swift-evolution] Compiler Warning on Unextended Classes

I would think this would not apply to public classes. There has also been discussion in the past about making final the default - I don’t remember if that ever resolved into some kind of consensus or not, though. l8r Sean > On Jun 16, 2016, at 11:23 AM, Saagar Jha via swift-evolution > wrote

Re: [swift-evolution] Compiler Warning on Unextended Classes

Correct me if I’m wrong, but if you’re writing some kind of framework and your class is not final but never subclassed, you wouldn’t want the warning, even if you’d like to allow users to subclass it? On Thu, Jun 16, 2016 at 9:02 AM Rehat Kathuria via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 5:36 PM, Paul Cantrell via swift-evolution > wrote: > >> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >> wrote: >> >> Protocols are a mechanism for deriving types from each other whereas >> generics are a way to parameterize types. My point was that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 8:55 AM, Paul Cantrell via swift-evolution > wrote: > > Right. Is that it? Are associated types really just generic protocols + > single conformance constraint + type params inferred / implied? A protocol and its associated types form a "package" or "group" of types that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 3:29 PM, Thorsten Seitz via swift-evolution > wrote: > > > >> Am 13.06.2016 um 04:04 schrieb Dave Abrahams : >> >> >> on Fri Jun 10 2016, Thorsten Seitz wrote: >> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution : > Am 09.

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> On Jun 16, 2016, at 9:55 AM, David Waite wrote: > > (repost) > > Two comments: > > - I’ll specifically call out that I think treating this as an alias rather > than a new platform is appropriate - it would be confusing for users if the > existing #if os(osx) did not match Sierra. > > - D

[swift-evolution] Compiler Warning on Unextended Classes

I’d like the compiler to present a warning when a class not declared as final is never subclassed. Thoughts? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 10:50 AM, Matthew Johnson wrote: > >> >> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This has been a point of confusion for me as well. I keep hearing that >> associated types are different from gene

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

(repost) Two comments: - I’ll specifically call out that I think treating this as an alias rather than a new platform is appropriate - it would be confusing for users if the existing #if os(osx) did not match Sierra. - Do you anticipate a separate proposal deprecating #if os(osx) ? -DW > On

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> On Jun 16, 2016, at 9:29 AM, Charlie Monroe via swift-evolution > wrote: > > Have you considered just #if os(mac)? I mean the fact that you're testing > against "OS" is already expressed. I know it goes against the other values > (watchOS, tvOS), but I'd personally drop those as well in fav

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution > wrote: > >> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Protocols are a mechanism for deriving types from each other whereas >> generics are a way to par

Re: [swift-evolution] API Guidelines: dropFirst?

I’ve always considered the term of art argument to be at least partially a red herring. These methods are difficult because you don’t have guarantees of non-mutability until you get to Collection - on Sequence, a dropFirst method may mean that neither the original nor returned sequence can addr

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

The changes in that patch were the minimum required to get it to build. There are definitely refinements to be had here, but I believe this gets us 90% of the way there (except corelibs-foundation which I will try to audit today after a rebase). I was only able to leave explicitly marked priva

Re: [swift-evolution] [DRAFT]

First apologies because I clearly messed up when sending. So can you re-ask your question on the version of this thread that isn't [DRAFT] followed by blank? Second, I do not anticipate deprecating osx because Swift will/can be deployed to OS X as well as macOS. I'll answer on the other thread

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

Have you considered just #if os(mac)? I mean the fact that you're testing against "OS" is already expressed. I know it goes against the other values (watchOS, tvOS), but I'd personally drop those as well in favor of simplier os(watch), os(tv). This would go along the various Swift 3 improvement

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution > wrote: > > Protocols are a mechanism for deriving types from each other whereas generics > are a way to parameterize types. My point was that Swift's other way to > parameterize types, namely by associated types, is very simil

Re: [swift-evolution] [DRAFT]

Two comments: - I’ll specifically call out that I think treating this as an alias rather than a new platform is appropriate - it would be confusing for users if the existing #if os(osx) did not match Sierra. - Do you anticipate a separate proposal deprecating #if os(osx) ? -DW > On Jun 16, 20

Re: [swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

> On Jun 16, 2016, at 9:29 AM, Charlie Monroe wrote: > > Have you considered just #if os(mac)? I mean the fact that you're testing > against "OS" is already expressed. I know it goes against the other values > (watchOS, tvOS), but I'd personally drop those as well in favor of simplier > os(wa

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 10:20 AM, Robert Widmann wrote: > > > > ~Robert Widmann > > 2016/06/16 8:18、Matthew Johnson > のメッセージ: > >> >>> On Jun 16, 2016, at 10:12 AM, Robert Widmann >> > wrote: >>> >>> The Swift PM case is actual

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

~Robert Widmann 2016/06/16 8:18、Matthew Johnson のメッセージ: > >> On Jun 16, 2016, at 10:12 AM, Robert Widmann >> wrote: >> >> The Swift PM case is actually the one that causes me to sound the alarm >> bells ;) I migrated that one by hand as did @modocache for XCTest. > > What I mean is that

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 10:12 AM, Robert Widmann wrote: > > The Swift PM case is actually the one that causes me to sound the alarm bells > ;) I migrated that one by hand as did @modocache for XCTest. What I mean is that you just applied the semantic-preserving transformation of replacing `priv

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

The Swift PM case is actually the one that causes me to sound the alarm bells ;) I migrated that one by hand as did @modocache for XCTest. ~Robert Widmann 2016/06/16 8:04、Matthew Johnson のメッセージ: > >> On Jun 16, 2016, at 9:49 AM, Robert Widmann wrote: >> >> Can you not see the links to the r

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 9:49 AM, Robert Widmann wrote: > > Can you not see the links to the rest of the corelibs changes in the > discussion? Then I'll reproduce them here Thanks. I don’t see anything unexpected here. The Swift PM case is one where the team wishes to take advantage of SE-002

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, Jonathan Hull wrote: > …Thus, I don’t really see the harm in renaming these to match the rest > of Swift. It won’t cause any confusion that can’t be easily recovered > from. I'm beginning to think you may be right. -- -Dave _

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, Brent Royal-Gordon wrote: >> What is the rationale behind the name dropFirst()? Being a > non-mutating method it should clearly be e.g. droppingFirst() > according to the API Naming Guidelines. > > Like many `Sequence` and `Collection` operations, `dropFirst()` is a > result

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Can you not see the links to the rest of the corelibs changes in the discussion? Then I'll reproduce them here - SwiftPM https://github.com/apple/swift-package-manager/pull/410 - XCTest https://github.com/apple/swift-corelibs-xctest/pull/124 - Foundation https://github.com/apple/swift-corel

Re: [swift-evolution] Bitshift operators

on Wed Jun 15 2016, Brent Royal-Gordon wrote: > While I was watching WWDC videos today, I noticed that there's a bit > of annoying boilerplate in OptionSet specifications, and set out to > get rid of it. Basically, what I'd like to do is this: > > extension OptionSet where RawValue: Intege

Re: [swift-evolution] Arbitrary-sized integers

on Tue Jun 14 2016, Félix Cloutier wrote: > I'm writing a program that would need Int128s. Since Swift uses LLVM > and LLVM has good support for arbitrary-sized integers (well, up to > 2^24 bits anyways), I was wondering if there was any interest in > having arbitrary-sized integers in Swift. T

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 9:30 AM, Robert Widmann wrote: > > Find it under our own pull requests on apple/swift#3000 You mean this one: https://github.com/apple/swift/pull/3000 right? What specifically did you want me to look at here? Of course this pro

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

That is for migration. It does not affect the semantics of private at any level, it merely explains how we should go about the initial transition. "In many cases" private being equivalent to fileprivate could be read that way, but given the rest of the proposal I didn't take any artistic freed

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Find it under our own pull requests on apple/swift#3000 ~Robert Widmann 2016/06/16 7:28、Matthew Johnson のメッセージ: > >> On Jun 16, 2016, at 9:23 AM, Robert Widmann wrote: >> >> Go checkout my branch! And see the discussion there for how your proposal >> has impacted corelibs. > > I’ll be hap

[swift-evolution] [DRAFT] Aliasing the OS X Platform Configuration Test

Starting in Sierra, Apple's Mac-based OS is renamed to macOS. All user-facing Swift APIs must go through Swift Evolution. While this is a trivial API change, I have put together a formal proposal as is normal and usual for this process. Here is a draft for public comment. -- Erica Gist: http

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 9:23 AM, Robert Widmann wrote: > > Go checkout my branch! And see the discussion there for how your proposal > has impacted corelibs. I’ll be happy to. Can you please provide a link to the branch and discussion? > > ~Robert Widmann > > 2016/06/16 5:50、Matthew Johnson

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 8:27 AM, Brent Royal-Gordon > wrote: > >> I am not convinced this is necessary. If there *is* a containing 'private' >> scope you can just leave the member unannotated to get this behavior. If >> there isn't you can use 'fileprivate' as it is already defined. Why is t

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Go checkout my branch! And see the discussion there for how your proposal has impacted corelibs. ~Robert Widmann 2016/06/16 5:50、Matthew Johnson のメッセージ: > > > Sent from my iPad > > On Jun 16, 2016, at 5:20 AM, Brent Royal-Gordon via swift-evolution > wrote: > >>> 6. With the core team t

[swift-evolution] [DRAFT]

Gist: https://gist.github.com/erica/f53fa6cfef9e5cf17ab139f7528edde2 Aliasing the OS X Platform Configuration Test Proposal: TBD Author: Erica Sadun Status: TBD Review manager: TBD

Re: [swift-evolution] Normalizing operator's types

> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution > wrote: > > Hi Swift, > > Since the "removal" of curried function, I am looking for some elegant ways > to work with partial functions (and reduce creation of closure and nested > func for the developper). > > And now I a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> Am 13.06.2016 um 04:04 schrieb Dave Abrahams : > > > on Fri Jun 10 2016, Thorsten Seitz wrote: > >>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >>> : >>> >>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution : >> on Wed Jun 08

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> I am not convinced this is necessary. If there *is* a containing 'private' > scope you can just leave the member unannotated to get this behavior. If > there isn't you can use 'fileprivate' as it is already defined. Why is that > not sufficient? Here's what's making me think about this: In

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Sent from my iPad On Jun 16, 2016, at 5:20 AM, Brent Royal-Gordon via swift-evolution wrote: >> 6. With the core team tied up at WWDC, you may want to temporarily forbid >> the use of `private` on a type and revisit the matter when people are less >> busy; if necessary, we could even ship S

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

Yes, using the same example, you can make required init to be convenience init: class MyBase { required init (coder: Int) { } required init (frame: Int) { } } class MyClass : MyBase { let x:Int let y:String let z:Double private init(isCoder: Bool, _ xValue: I

Re: [swift-evolution] API Guidelines: dropFirst?

…Thus, I don’t really see the harm in renaming these to match the rest of Swift. It won’t cause any confusion that can’t be easily recovered from. I was outvoted on that though… Thanks, Jon > On Jun 16, 2016, at 5:01 AM, Jonathan Hull wrote: > > I mean that *IF* we were to rename ‘map’ to

Re: [swift-evolution] API Guidelines: dropFirst?

I mean that *IF* we were to rename ‘map’ to ‘mapped’, the compiler would catch this and could recommend the new name. Even if we add a mutating version called ‘map’, it would still catch this case because the mutating version would have a void return. Thanks, Jon > On Jun 16, 2016, at 4:57 AM

Re: [swift-evolution] API Guidelines: dropFirst?

> The signatures are also different, so: > > let newList = list.map(…) > > would throw an error because I have the signature wrong. I'm not sure what you mean by this. What is the error? Why? Does it have something to do with the code you imagine is elided by the ellipses? -- Brent Royal-Gord

Re: [swift-evolution] API Guidelines: dropFirst?

> That said I actually think it’s useful to have these methods slightly > different as if I understand them correctly they’re not strictly > non-mutating; a Sequence doesn’t guarantee that it can be consumed over and > over without changing, as it could represent a buffer or some other construct

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

I’m not really interested in a really rich language, just the most simple thing possible that lets me create rich apps. I like Vladimir’s description of there being more when you need it. (I guess what I am concerned about is complexity as a writer. I want everything to be as consistent and log

Re: [swift-evolution] API Guidelines: dropFirst?

I actually think we should use ‘mapped’, ‘filtered’, and ‘reduced’ instead of the “Terms of Art”. They start with the same words, so anyone looking for ‘map’, ‘filter’, and ‘reduce’ will see them in the autocomplete. The signatures are also different, so: let newList = list.map(…) would throw

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

There's nothing stopping you from making init(frame:) and init?(coder:) convenience: public class ColorView: NSView { public required convenience init?(coder: NSCoder) { self.init(frame: CGRect(x: 0.0, y: 0.0, width: 20.0, height: 20.0)) }

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

Good question/idea. The use case I have with this most often is -initWithCoder and some other init like -initWithFrame. I don’t think you can make those convenience inits. If there is a way to make that work though, I am all for it. The thing I do most often, when possible, is lazily set each

Re: [swift-evolution] Bitshift operators

Brent Royal-Gordon wrote: > While I was watching WWDC videos today, I noticed that there's > a bit of annoying boilerplate in OptionSet specifications, and > set out to get rid of it. Basically, what I'd like to do is this: > > extension OptionSet where RawValue: Integer { > init(b

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

The question is if we can solve the problem with special private init() and convenience inits ? class MyBase { init () { } } class MyClass : MyBase { let x:Int let y:String let z:Double private init(_ xValue: Int, _ zValue: Double) { self.x = xValue se

Re: [swift-evolution] API Guidelines: dropFirst?

> On 16 Jun 2016, at 08:39, Brent Royal-Gordon via swift-evolution > wrote: > >> What is the rationale behind the name dropFirst()? Being a non-mutating >> method it should clearly be e.g. droppingFirst() according to the API Naming >> Guidelines. > > Like many `Sequence` and `Collection` op

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> 6. With the core team tied up at WWDC, you may want to temporarily forbid the > use of `private` on a type and revisit the matter when people are less busy; > if necessary, we could even ship Swift 3 that way. Or you may want to > consider making a guess as to a good implementation model to ap

Re: [swift-evolution] API Guidelines: dropFirst?

On 16.06.2016 10:39, Brent Royal-Gordon via swift-evolution wrote: What is the rationale behind the name dropFirst()? Being a non-mutating method it should clearly be e.g. droppingFirst() according to the API Naming Guidelines. Like many `Sequence` and `Collection` operations, `dropFirst()` is

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

From the Impact portion of the proposal: > The existing code will need to rename private to fileprivate to achieve the > same semantics. In many cases the new meaning of private is likely to compile > as well and the code will then run exactly as before. I believe the second sentence refers to t

  1   2   >