Re: [swift-evolution] String update

matically typing them to arrays? > > let name = / > (let firstName: String <- \w+) \s > (let initials: [String] <- \w)* \s > (let lastName: String <- \w+) > / > print(type(of: name)) // => Regex<(firstName: String, initials: [Character], > lastName:

Re: [swift-evolution] String update

Significant leading zeros is a good point. Another would be non-default-radix. > On Jan 16, 2018, at 12:22 PM, C. Keith Ray via swift-evolution > wrote: > > people may want digits as characters in order to see zeros. parsing phone > numbers and social security

Re: [swift-evolution] String update

>> ``` >>>> let decimal = /let beforeDecimalPoint: Int <-- >>>> .numberFromDigits(.oneOrMore)/ + >>>> .optional("." + /let afterDecimalPoint: Int <-- >>>> .numberFromDigits(.oneOrMore)/ >>>> ``` >>>

Re: [swift-evolution] String update

ng = \w)(let trailing = \w+)｣ // Regex<(leading: Substring, trailing: Substring)>, or perhaps Regex<(leading: Character, trailing: Substring>), details…. switch input { case let (first, rest) <- peelFirstWordChar: print(“\(first) \(rest)”) } > This is explored in the attached playground (rep

[swift-evolution] String update

Hello, I just sent an email to swift-dev titled "State of String: ABI, Performance, Ergonomics, and You!” at https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html, whose gist can be found at https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f. I posted to

Re: [swift-evolution] Zero-copy String buffer access

> On Nov 3, 2017, at 10:39 AM, Cory Benfield via swift-evolution > wrote: > > One of Swift’s major advantages as a language is the ease of bridging from > Swift code to C. This ease makes it possible to utilise the vast body of > existing code to bootstrap

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

We are definitely looking at it, soon. Right now (working on Swift 4.1), most of the String focus is on ABI-critical concerns, but better String APIs and programming models is a focus area for Swift 5. > On Oct 25, 2017, at 3:34 PM, Kelvin Ma via swift-evolution >

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

> On Oct 18, 2017, at 12:24 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > >> >> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> >>

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

> On Oct 17, 2017, at 2:08 PM, Kevin Nattinger wrote: > >> >> On Oct 17, 2017, at 11:47 AM, Michael Ilseman > > wrote: >> >> >> >>> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >>>

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

> On Oct 17, 2017, at 1:36 PM, Benjamin G wrote: > > > > On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman > wrote: > > >> On Oct 17, 2017, at 12:54 PM, Benjamin G >

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

17 Oct 2017 at 21:00, Jonathan Hull via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Oct 17, 2017, at 11:47 AM, Michael Ilseman via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@s

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

but might fight some bugs. I think that of all the dichotomies we fail to model in our protocol hierarchy, the ordered vs unordered is the least useful to accommodate. It is, however, easy and fun to bike shed. > On Tue, Oct 17, 2017 at 8:47 PM, Michael Ilseman via swift-evolution > <swi

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

> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution > wrote: > >> Because, in my analysis, the problem is that the method is incorrectly >> named. The problem affects all types that conform to Sequence and not just >> Set and Dictionary;

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

A Set has indices because they are useful to use with the type. Regardless of whether Set conforms to Collection, or even Sequence, indices are useful and meaningful for Sets. Even if the entire protocol hierarchy were to be redesigned, Set would provide indices. If Set didn’t implement any

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

Sets being values are not an implementation detail. They have value semantics, and that is part of the guarantee of the type. This is perhaps the most important concept in the standard library. > On Oct 16, 2017, at 10:27 AM, Kevin Nattinger wrote: > >>> >>> How is the

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

> On Oct 16, 2017, at 8:46 AM, David Sweeris via swift-evolution > wrote: > > > On Oct 16, 2017, at 07:20, Xiaodi Wu via swift-evolution > > wrote: > >> >> On Mon, Oct 16, 2017 at 05:48 Jonathan Hull

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

> On Oct 16, 2017, at 7:20 AM, Thorsten Seitz via swift-evolution > wrote: > > > > Am 16.10.2017 um 07:19 schrieb Xiaodi Wu >: > >> On Sun, Oct 15, 2017 at 11:57 PM, Thorsten Seitz >

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

That is what == does: https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb#L1267 > On Oct 15, 2017, at 1:25 PM, C. Keith Ray via swift-evolution > wrote: > > Why not use an equals Implementation that doesn't rely on order? > >

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

I think that “match” is a word to avoid for this, as this doesn’t have anything to do with pattern matching, fuzzy matching, etc., while “equals” is precisely the concept we’re using. What about the name “sequentiallyEquals”? Highlight the fact that we’re talking about sequential ordering,

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

> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger wrote: > >> >> On Oct 13, 2017, at 10:01 AM, Michael Ilseman > > wrote: >> >> >> >>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution >>>

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

> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution > wrote: > > –∞ > > 1. I strongly object to the proposed name. It doesn't make it more clear to > me what the method does, and is misleading at best. Among other issues, > "lexicographical" is

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Another benefit of the always-emit-into-client-and-omit-from-libary-binary is cross-call consistency. A function foo could change in a way such that *all* calls using either the new or old version is fine, but some interleaving of calls to new and old versions is invalid. Having to reason about

Re: [swift-evolution] StringProtocol - Do not declare new conformances?

Out of curiosity, how are your other string types different from Swift String? > On Sep 19, 2017, at 3:34 PM, Braden Scothern via swift-evolution > wrote: > > Where I work we are writing a C library for cross platform development on > iOS, Android, and Ubuntu. Part

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 1, 2017, at 10:27 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing > methods, adjust existing labels for clarity, and remove deallocation size" > begins

Re: [swift-evolution] Persistent Collections with full COW support

Can you link to the SPM package so people can play around with it? > On Sep 1, 2017, at 8:26 AM, Sebastian Bohmann via swift-evolution > wrote: > > Is swift evolution interested in a set of persistent collections (vector, > hashset, hashmap) with full cow support

Re: [swift-evolution] SE-184 Improved Pointers

This is an excellent, thoroughly thought out, and well written proposal! I’m eager to see these improvements land. > On Aug 22, 2017, at 11:33 AM, Taylor Swift wrote: > > > > On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution > wrote: > > >> On Aug 20, 2017, at 6:03 PM, Taylor Swift > > wrote: >> >> New draft of the proposal is up here: >>

Re: [swift-evolution] typed throws

Wouldn’t switching from `async` to `async throws` be both a source and ABI break for libraries? If so, there is a library evolution argument to `async` also encompassing throws as a reasonable default. It's likely that the non-throwing-ness of many `async` operations is an artifact of the

Re: [swift-evolution] Draft: Regular Expression in Swift

Thank you for bringing this up! Swift String has a lot of expressivity gaps we’re trying to tackle in Swift 5. I think that both language and library support for flexible matching and transformation is needed, likely through a regex-like construct. Libraries and prototypes like this help drive

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

> On Aug 9, 2017, at 4:09 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now and runs through August 15, 2017. The proposal is available here: >

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

The key difference is whether such things can be rolled out in the future in an additive way, potentially with extra compatibility affordances, vs whether something is inherent to the ABI as Swift and the standard library currently exists. This is a very fuzzy line, and is constantly getting

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution > wrote: > > >> So, this has been discussed before on the list many times in the past. The >> core team has stated that their preferred process for this is to have >> individuals write their own

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 10:03 AM, Tino Heth via swift-evolution > wrote: > >> But linear access isn’t an inherent canonical property of multi-dimensional >> arrays, it’s just a consequence of arrays taking a contiguous block of >> memory (which is generally treated

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution > wrote: > > I’ve noticed from this and older threads that everyone agrees on what core > libraries we want, but they never actually get built. Perennial requests seem > to be > > - RNG and

Re: [swift-evolution] Fast String Comparison From String Arrays

This sounds like an interesting idea. The best way to promote this would be to make a Swift package first, so that Swift users can use it right away and we can see how it works in practice. If it has sufficient merit and general applicability, then it makes sense to propose including it in the

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

I agree with all of Andy’s points. I really like this and think it’s a good time to start discussing its details and moving from a pitch to a proposal. Thank you for writing it! Minor tweak: say “deprecate” instead of “remove” for APIs, which has a better connotation with respect to source

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

> On Jul 13, 2017, at 6:55 PM, Taylor Swift via swift-evolution > wrote: > > > > On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick > wrote: > >> On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution >>

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

If you’re considering moving allocate/deallocate to Unsafe*BufferPointer, then you probably also want to consider doing the same for initialize, deinitialize, and various move functions as well. > On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution >

Re: [swift-evolution] JIT compilation for server-side Swift

> On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution > wrote: > > Hi, > > Last year a small group of developers from the IBM Runtimes compiler team > undertook a project to explore JIT compilation for Swift, primarily aimed at > server-side Swift. The

Re: [swift-evolution] JIT compilation for server-side Swift

No, this is completely unrelated. This is about runtime optimization of already-running swift programs. > On Jul 10, 2017, at 10:40 AM, Jacob Williams via swift-evolution > wrote: > > Pardon my lack of knowledge about JIT compilation, but does this open the >

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

This is really cool! I second Jacob’s request for nightlies. Many things in the Swift compiler are architected similarly to Clang (inspired by Clang), so hopefully any features the explorer can do for C++ it could do for Swift as well. The swift compiler dump ASTs similarly to Clang with e.g.

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 11, 2017, at 10:25 PM, David Hart via swift-evolution > wrote: > > > On 11 Jun 2017, at 02:49, Ben Cohen > wrote: > >> >>> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 4:34 PM, Jens Persson wrote: > > The analogy of the special first parameter label was relevant (for me) in > that it was a special rule that was invented to resolve a problem/situation > with no clear best solution. Probably most people agree now that

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution > wrote: > > The point of exercise 1 is to show that it is impossible (in Swift 4) to > write a generic function composition operator (or function) which works as > expected for any reasonable

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

If you replace “heap access” with “heap allocation/deallocation” in the argument, then the performance differences become very relevant. > On May 31, 2017, at 10:15 AM, David Waite via swift-evolution > wrote: > > >> On May 31, 2017, at 9:28 AM, Robert Bennett via

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

> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution > wrote: > > > Pretty version: > https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/-string-index-overhaul.md > > > > # String Index Overhaul > > *

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 11, 2017, at 12:56 PM, Ben Cohen via swift-evolution > wrote: > > >> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon > > wrote: >> >>> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >>>

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

If an extension on your type declares a hashValue property, what should be the semantics? Is that an error (conflicts with default provided one), or is that one used? > On May 4, 2017, at 3:20 PM, Andrew Bennett via swift-evolution > wrote: > > That's correct,

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

My understanding is that there is no mechanism yet to guarantee stack allocation for anything. > On Apr 17, 2017, at 3:29 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution >> <swift-evolution@swi

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

This is the best approach that I’m aware of. It does bake in an ABI assumption that the tuple layout will be contiguous and strided/addressable. Monitor https://bugs.swift.org/browse/SR-3726 for changes here. Note that you can also a little more “pure” in a sense if you construct an

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

-1 While I believe that "fileprivate is the one true private" and was opposed to how SE-0025 turned out, this doesn’t fix access control. It introduces language churn without a replacement solution during a time when source compatibility is very important. The cognitive retraining price was

Re: [swift-evolution] Smart KeyPaths

> > On Mar 17, 2017, at 3:24 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 17, 2017, at 3:17 PM, Michael LeHew via swift-evolution >> > wrote: >> >> One thing that gets interesting with

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution > wrote: > > Ted, > > It might have helped if instead of being called String and Character, they > were named Text I would oppose taking a good name like “Text” and using it for Strings which are

Re: [swift-evolution] Strings in Swift 4

Given that the behavior you desire is literally a few key strokes away (see below), it would be unfortunate to pessimize the internal representation of Strings for every application. This would destroy the applicability of the Swift standard library to entire areas of computing such as

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

A quick note addressing a misconception that you’ll want to clean up for a formal proposal: NS_[EXTENSIBLE_]STRING_ENUMs both generate Swift structs, the difference is only in the explicitness of the rawValue initializer. To use the “other direction” analogy, you’d similarly want them to apply

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

> On Feb 20, 2017, at 9:09 AM, David Hart via swift-evolution > wrote: > > >> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution >> > wrote: >> >> I'm developing an application where we use

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 1:44 PM, Tanner Nelson wrote: > > To give a concrete example, some of the issues have arisen from using enums > as Swift.Errors. > > ``` > public enum SocketError: Error { > case closed > } > ``` > > Then we find some new error that was

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 1:21 PM, Tanner Nelson wrote: > > That's awesome. It looks like `(planned) Open and closed enums` is exactly > what I'm looking for. > > Would it help if I created a concrete proposal for that or is it something > the Swift team already has brewing?

Re: [swift-evolution] Warning when omitting default case for imported enums

BTW, this will likely be part of the eventual design of “open”/resilient enums ala https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums. There, the goal is to reduce both ABI and source breakage caused by this sort of thing. It seems like for your purposes, you’re less

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 26, 2017, at 7:29 PM, Ted Kremenek > wrote: > >> >>> On Jan 26, 2017, at 12:19 PM, Matthew Johnson

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 1:02 PM, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have

Re: [swift-evolution] Swift ABI Stability Manifesto

ume Lessard <gless...@tffenterprises.com> > wrote: > > >> On 25 janv. 2017, at 14:16, Michael Ilseman via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> An example of a type that is neither trivial nor bitwise movable is a struct >> co

Re: [swift-evolution] warnings for out of scope?

This seems best handled as a lint rule, probably filed under “pedantic”. It makes sense to apply to a project at certain milestones, but could be noisy during incremental development. > On Jan 25, 2017, at 12:25 AM, Dave Kliman via swift-evolution > wrote: > > Hi!

Re: [swift-evolution] Swift ABI Stability Manifesto

> On Jan 26, 2017, at 3:12 AM, Dale Buckley > wrote: > >> I put together a document compiling many conversations with many people >> about Swift’s ABI and what needs to happen prior to ABI stability. It is >> meant to be a blueprint for the project on how to

Re: [swift-evolution] A case for postponing ABI stability

As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable , it primarily enables OSes to ship with a copy of the standard

[swift-evolution] Swift ABI Stability Manifesto

I put together a document compiling many conversations with many people about Swift’s ABI and what needs to happen prior to ABI stability. It is meant to be a blueprint for the project on how to approach and achieve ABI stability, as well as a resource to the community. It can be viewed fully

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 24, 2017, at 12:12 AM, Tino Heth via swift-evolution > wrote: > > Imho the major problem is that there's quite a lot confusion about what ABI > stability actually means — and a lot uncertainty which proposals would > actually affect it. I’m hoping to

Re: [swift-evolution] Default Generic Arguments

> On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution > wrote: > > The proposal looks good to me with one possible concern. I'm leaning toward > types that use the defaults should still require the angle brackets, X<>. > This makes it clear that you're

Re: [swift-evolution] Generic Subscripts

[Forgot to CC swift-evolution the first time] When this came up last, it was seen as more so a bug in the current implementation, rather than an explicit choice. There's no need for a proposal, just a JIRA: https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Are you asking for a class declaration to implicitly capture and extend the lifetime of local variables? That seems like something that’s better done explicitly. Perhaps it’s better to think about how to reduce the boiler plate code, e.g. better default initializers. (this is of course,

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On Dec 14, 2016, at 6:32 PM, Kevin Ballard via swift-evolution > wrote: > > On Wed, Dec 14, 2016, at 05:54 PM, Brian King wrote: >>> Please no. Just because I have to subclass NSObject doesn't mean I want to >>> discard the performance benefits of static dispatch,

Re: [swift-evolution] Add code to super methods.

> On Nov 28, 2016, at 7:22 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Nov 24 2016, Michael Ilseman wrote: > >>> On Nov 17, 2016, at 2:54 AM, Tino Heth via swift-evolution >> wrote: >>> >>> An

Re: [swift-evolution] Add code to super methods.

> On Nov 17, 2016, at 2:54 AM, Tino Heth via swift-evolution > wrote: > > An equivalent of "NS_REQUIRES_SUPER" (hopefully with a better name ;-) has > been requested several times, but never got the momentum it deserves. > Considering the current confusion

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

> On Oct 4, 2016, at 9:32 AM, Michael Ilseman via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution > wrote: > > SE-0111 established that Swift's type system would not allow function > argument labels to be expressed as part of a function type. As I've been > working with curried functions, I'm

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

>> >>> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution >>>>

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

It seems like there’s a potential for confusion here, in that people may see “UInt8” and assume there is some kind of typed-ness, even though the whole point is that this is untyped. Adjusting the header comments slightly might help: /// A non-owning view of raw memory as a collection of

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On Aug 9, 2016, at 1:01 PM, Charles Srstka via swift-evolution > wrote: > >> On Aug 9, 2016, at 2:09 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> Hi Everybody, >> >> With another round of apologies for taking late action,

Re: [swift-evolution] Swift 3.1 vs Swift 4

I’m sorry, but Whisky for the Core Team is an additive feature and will have to be deferred until Swift 4. > On Jul 25, 2016, at 10:37 PM, Charlie Monroe via swift-evolution > wrote: > > I was kind of serious about this. I'll set up a pool on >

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 7:37 AM, Brad Hilton via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > -1. Argument labels can have meaning and are very useful, especially for > default parameter names in closures: > > ```// Declaration > func

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 1:30 AM, Taras Zakharko via swift-evolution > wrote: > > Jordan, Thanks for the very insightful explanation! It all makes a lot of > sense in perspective. > > Apparently I was thinking about this issue a bit while I was sleeping, and > now it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

rABToC(with:until:) : (A, B) -> C = foo(a:b:) var myC = higherOrderABToC(with: myA, until: myB) higherOrderABToC = bar(from:using:) myC = higherOrderABToC(with: myA, until: myB) > On Jun 30, 2016, at 4:16 PM, Michael Ilseman via swift-evolution > <swift-evolution@swift.org> wro

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

name, because they are prepositional > phrases. Knowing that the Provider is "for" something and something does > something "with" the ShippingManifest is absolutely useless to anyone reading > the code where the method name those labels are part of isn't immediately > obvious.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

> On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution > wrote: > > -1 > > This proposal doesn’t even use Swift naming style to make its point, as soon > as you do, the reason why Swift considers argument labels to be part of the > type signature

Re: [swift-evolution] Notification.Name

> On Jun 30, 2016, at 9:10 AM, Ben Rimmington wrote: > > [Cc: Michael Ilseman] > >> On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution >> wrote: >> >> Not 100% sure this belongs here, but I'll bite. >> >> The new

Re: [swift-evolution] [Proposal] Sealed classes by default

I was also referring to how we present Objective-C classes in Swift. That is, if a Swift user tries to subclass an Objective-C-imported class, then we’d take into account sealed-ness in order to issue an error/warning, etc. If you are also proposing a Clang attribute for this, e.g.

Re: [swift-evolution] [Proposal] Sealed classes by default

Could you elaborate on how we should treat classes imported from Objective-C or CF-style C? That is, do we always annotate them as being “open” because those paradigms permit subclassing anywhere, or do you propose some kind of recommended “sealed” audit, or what? > On Jun 27, 2016, at 3:40

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

> On Jun 6, 2016, at 3:51 PM, Ben Rimmington via swift-evolution > wrote: > > SE-0033 and SE-0044 are already "Implemented in Swift 3" according to both > the proposals and the README, but not according to the bug tracker: > >

[swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

During implementation, I’ve come up with some problems with SE-0033  as written, and am proposing some changes to the proposal. I’d like to present them here for early discussion, and will write up a

Re: [swift-evolution] Crypto routines as part of the core library

Great! I will watch that thread as it’s something I’m also interested in knowing more about. Thanks for bringing it up! > On Apr 14, 2016, at 2:51 PM, Travis Beech > wrote: > > Thanks Michael for the input. I realized that after your last response I was > indeed

Re: [swift-evolution] Crypto routines as part of the core library

> On Apr 14, 2016, at 2:42 PM, Travis Beech > wrote: > > It should be provided by Swift, not some unknown developer out on Github, no > matter how good his\her credentials are. I see core libraries as part of the > language runtime. If you look at other modern

Re: [swift-evolution] Crypto routines as part of the core library

Why would it need to be built into the language proper instead of the core libraries? I am not too familiar with the core libraries, but perhaps swift-corelibs-dev is the more appropriate mailing list here? > On Apr 13, 2016, at

Re: [swift-evolution] Notes from Swift core team 2016-04-05 design discussion

I don’t think the notes were conveying a decided-upon solution, so much as a fervent discussion which did not yet yield a conclusion. If you have an idea of how to address this, could you put together a draft? > On Apr 6, 2016, at 3:39 AM, Антон Жилин via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Updated proposal with https://github.com/apple/swift-evolution/pull/226 I went with option #2 as recommended. > On Mar 23, 2016, at 10:27 AM, Douglas Gregor wrote: > > >> On Mar 22, 2016, at 9:30 PM, Brent Royal-Gordon >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 22, 2016, at 6:03 PM, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Mar 22, 2016, at 17:21, Michael Ilseman via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

of a protocol extension, they remain static dispatch and off of the protocol type. When we figure out subscript, I’ll amend the proposal to call these out. > On Mar 22, 2016, at 5:21 PM, Michael Ilseman <milse...@apple.com> wrote: > > > >> On Mar 17, 2016, at 11:45 AM, M

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 17, 2016, at 11:45 AM, Michael Ilseman via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Thanks for pointing out the ambiguity! I added an amendment to the proposal in https://github.com/apple/swift-evolution/pull/214 > On Mar 16, 2016, at 4:58 AM, Michel Fortin wrote: > > Le 15 mars 2016 à 20:31, Michael Ilseman a écrit : > >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> • What is your evaluation of the proposal? >> >> Overall in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 15, 2016, at 5:12 PM, Michel Fortin via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > Looks like a very good idea. Less wrapper code means less possibility of an > error, a less cluttered call stack when debugging, and faster

  1   2   >