Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

On 23.02.2017 21:04, Matthew Johnson wrote: On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: I'm really sorry to interrupt your discussion, but could someone describe(or point to some article etc) in two words why we need added complexity of typed throws(in comparing to use documentation) Th

[swift-evolution] Setting expectations on when we move to Discourse

Hi everyone, Moving to Discourse (from the mailing lists) is something that is being scoped out, but I wanted to lay some expectations that the move will not be immediate. The reason is that the people who would do the work on making the transition were already busy with already planned infrast

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

What's the status of Recursive protocol constraints? it's a feature that will help the design of a library I'm working on. How can I help ? On Tue, Feb 14, 2017 at 1:32 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 13, 2017, at 1:42 PM, Charles Srstka via sw

Re: [swift-evolution] Setting expectations on when we move to Discourse

Hi Ted, Is that the reason why the mailing list was down for 24 hours? --  Adrian Zubarev Sent with Airmail Am 24. Februar 2017 um 19:18:31, Ted kremenek via swift-evolution (swift-evolution@swift.org) schrieb: Hi everyone, Moving to Discourse (from the mailing lists) is something that is b

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:24 PM, Karl Wagner wrote: > > It’s funny, I literally just came across this. Turns out this is what the > Dispatch overlay uses for dispatch_sync/DispatchQueue.sync. > > Here’s an even shorter example: > > func throwsUnexpected(one: ()throws->Void, hack: (Error)throws

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:30 PM, Anton Zhilin wrote: > > 2017-02-23 21:01 GMT+03:00 Matthew Johnson >: > I don’t understand what you mean here. > > I was a bit confused. Thanks to your clarification, I discovered that > `rethrows` functions currently can use `thr

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

Sending to mailing list: > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > wrote: > > # Analysis of the design of typed throws > > ## Problem > > There is a problem with how the proposal specifies `rethrows` for functions > that take more than one throwing function. The prop

[swift-evolution] [Pitch] CRTP in Swift

First of all, writing CRTP is already allowed in Swift, however it doesn’t work at all. For example one would assume that the output of the following code sample might look like this 1 2 3 4: print(1) class Template {} class RealThing : Template { override init() { print(2) } func foo

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 24, 2017, at 3:59 AM, Anton Mironov wrote: > >> >> On Feb 23, 2017, at 3:55 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 23, 2017, at 4:40 AM, Anton Mironov >> > wrote: >>> >>> On Feb 23, 2017, at 4:28 AM, Matt

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 23, 2017, at 3:55 PM, Matthew Johnson wrote: > >> >> On Feb 23, 2017, at 4:40 AM, Anton Mironov > > wrote: >> >> >>> On Feb 23, 2017, at 4:28 AM, Matthew Johnson >> > wrote: >>> On Feb 22, 2017, at 7:13 PM, An

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Does swift still use #? foo(#) It might be more obvious then foo(_) People might mistake it for foo(_:) if they are just glancing at it. But foo(#) looks special. On Thu, Feb 23, 2017 at 1:07 PM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > FWIW, I do think the foo(_) i

[swift-evolution] Additive proposals

Dear core team, I would love to have a clear statement on when purely additive proposals will be in scope of Swifts evolution? There are quite a few proposals that are marked as ‘out of scope’ since the last phase of pre Swift 3 development. Sure these proposals do not focus on huge improvement

[swift-evolution] [pitch] Atomics

There is no clean way to use atomic operations in Swift at the moment, even less so after most of OSAtomic.h was deprecated in Sierra. Of course, the OSAtomic calls were never available in Linux, so there are no atomics at all on that side. It's technically possible to wrap clang’s C11 atomics f

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 23, 2017, at 10:36 PM, Russ Bishop wrote: > > >> On Feb 21, 2017, at 8:18 AM, Joe Groff > > wrote: >>> >>> Yeah but Rust has a macro system so error-chain makes re-wrapping trivial. >>> A simple `chain_err(|| “my new error message”)` is enough to define

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 24, 2017, at 12:06 PM, David Hart wrote: > > Sending to mailing list: > > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> # Analysis of the design of typed throws >> >> ## Problem >> >> There is a problem with how the p

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 3:31 PM, Vladimir.S wrote: > > Thank you for replies, Matthew. They were very helpful to understand the > proposed solution. You’re welcome. Happy to help! > > On 23.02.2017 21:04, Matthew Johnson wrote: >> >>> On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: >>> >>>

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 1:03 PM, Vladimir.S wrote: > > On 23.02.2017 21:04, Matthew Johnson wrote: >> >>> On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: >>> >>> I'm really sorry to interrupt your discussion, but could someone >>> describe(or point to some article etc) in two words why we need

Re: [swift-evolution] [Pitch] Typed throws

> On 23 Feb 2017, at 17:19, Joe Groff wrote: > >> >> On Feb 23, 2017, at 12:06 AM, Karl Wagner wrote: >> >> >>> On 22 Feb 2017, at 21:13, Joe Groff wrote: >>> On Feb 21, 2017, at 8:50 PM, Chris Lattner via swift-evolution wrote: On Feb 20, 2017, at 11:12 PM, Jo

Re: [swift-evolution] Strings in Swift 4

> On 23 Feb 2017, at 02:24, Dave Abrahams wrote: > > Equally a non-starter. All known threadsafe schemes that require caches to be > updated upon non-mutating operations have horrible performance issues, and > further this would penalize all string code by reserving space for the cache > and

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 23 Feb 2017, at 18:25, Vladimir.S wrote: > Weird idea, why not have function name just after arguments block, without > any separator: > > func adding(_ other:Self) -> Self > func adding(_ other:Self)reportingOverflow -> (Self, Bool) > > let resultOnly = a.adding(b) > let resultReportingO

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

Thank you for replies, Matthew. They were very helpful to understand the proposed solution. On 23.02.2017 21:04, Matthew Johnson wrote: On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: I'm really sorry to interrupt your discussion, but could someone describe(or point to some article etc) in

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

Free functions generally work with autocomplete, however they have some disadvantages: 1. You can't easily find them when browsing with something like SwiftDoc or looking at headers via control-click in Xcode 2. Some of the compiler writers have commented that free functions slow the compiler

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 1:34 PM, Joanna Carter > wrote: > > >> Le 23 févr. 2017 à 14:59, Matthew Johnson a écrit : >> >> The rationale for this is that it allows you to explore the eventual design >> of a type without exposing it. When you are confident in the design all you >> need to does

Re: [swift-evolution] [Pitch] CRTP in Swift

> On Feb 23, 2017, at 10:54 AM, Adrian Zubarev via swift-evolution > wrote: > > First of all, writing CRTP is already allowed in Swift, however it doesn’t > work at all. > > For example one would assume that the output of the following code sample > might look like this 1 2 3 4: > > print(

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 24, 2017, at 11:00 AM, Joe Groff via swift-evolution > wrote: > > >> On Feb 23, 2017, at 10:36 PM, Russ Bishop > > wrote: >> >> >>> On Feb 21, 2017, at 8:18 AM, Joe Groff >> > wrote: > Yeah but Rust has a macro system

[swift-evolution] [Draft] scope-based submodules

I didn't expect submodules to be a part of the Swift 4 discussion. When it came up I was pleasantly surprised. I have been thinking about the design of a submodule system for quite a while but was planning to wait until it was clearly in scope to draft a proposal. Now that the topic has been

Re: [swift-evolution] [pitch] Atomics

+1 But I would also suggest using Int instead of Int64 in public interface. > On Feb 23, 2017, at 23:44, Guillaume Lessard via swift-evolution > wrote: > > There is no clean way to use atomic operations in Swift at the moment, even > less so after most of OSAtomic.h was deprecated in Sierra.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution > wrote: > >> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> My apologies for misunderstanding. >> >> Would it be better to add the anonymous case feature in a separat

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

It’s funny, I literally just came across this. Turns out this is what the Dispatch overlay uses for dispatch_sync/DispatchQueue.sync. Here’s an even shorter example: func throwsUnexpected(one: ()throws->Void, hack: (Error)throws->Void) rethrows { try hack(SomeUnexpectedError.boo) } func hac

Re: [swift-evolution] Strings in Swift 4

> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > >> On 23 Feb 2017, at 02:24, Dave Abrahams > > wrote: >> >> Equally a non-starter. All known threadsafe schemes that require caches to >> be updated upon non-mutating operations ha

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

When I started changing the proposal, I noticed that examples with throws(E) look uglier than with rethrows, because of required constraint of E: Error. So I’d like to also discuss removal of Error constraint and its consequences. Some people talked about Objective-C interop. What are those issues?

[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

*Introduction* There has been a deluge of discussion about access levels lately, all attempting to simplify the situation. Shortly after Swift 3 was released, many people realized that the new access modifier story was far more complex than the old one, and expressed the belief that the changes ma

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 21:01 GMT+03:00 Matthew Johnson : > > I don’t understand what you mean here. > I was a bit confused. Thanks to your clarification, I discovered that `rethrows` functions currently can use `throw` expression, but only in `catch` scope, which handles error handling for one of function par

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

+1 to foo(:) version. I can easily see placeholder arguments as a sugary syntax for closures: func bar(_ x: Int, _ y: Double) let f = bar(_, 42) // the same as: let f = { (x: Int) in bar(x, 42) } Now, let’s view a single-parameter version: func foo(_ x: Int) let f = foo(_) // the same as: le

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other F

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 23, 2017, at 12:52 PM, Anton Zhilin via swift-evolution > wrote: > > +1 to foo(:) version. > I can easily see placeholder arguments as a sugary syntax for closures: > This shorthand has been explicitly rejected several times in favor of the $ argument shorthand. > func bar(_ x: Int,

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Thanks for that very well written pitch! Not only I think it summarizes most of the opinions I remember reading across the “myriad” of discussion, but it also proposes a quite reasonable reshaping of the system. There’s just (in my pov) one additional argument in favour of that proposal that I’

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 23 Feb 2017, at 19:40, Max Moiseev wrote: > > Conformance to Comparable is not required by anything in the standard > library. Besides, it is always possible to further constrain your own code as > in: > Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of stuff, actu

Re: [swift-evolution] [pitch] Atomics

Huge +1, and for the prototype as well. Atomic.Bool and Atomic.RawPointer would also be truly appreciated. An Atomic a la C++ would be even better but I don't know if we'd want to tie ourselves to that. I like the LLVM names for MemoryOrder et. al. better than the C std. ones, in general, and have

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 23.02.2017 17:35, Haravikk wrote: On 23 Feb 2017, at 12:49, Vladimir.S mailto:sva...@gmail.com>> wrote: On 23.02.2017 14:17, Haravikk wrote: On 22 Feb 2017, at 21:25, Patrick Pijnappel mailto:patrickpijnap...@gmail.com> > wrote: To summarize, there's o

Re: [swift-evolution] Strings in Swift 4

Exactly. Sent from my moss-covered three-handled family gradunza > On Feb 24, 2017, at 9:49 AM, David Sweeris wrote: > > >>> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution >>> wrote: >>> >>> >> >>> On 23 Feb 2017, at 02:24, Dave Abrahams wrote: >>> >>> Equally a n

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 12:43 PM, David Sweeris wrote: > > > > > Sent from my iPhone >> On Feb 23, 2017, at 10:40, Max Moiseev wrote: >> >> Conformance to Comparable is not required by anything in the standard >> library. > > That surprises me. Isn't there a sort function or something, or d

Re: [swift-evolution] [pitch] Atomics

> On Feb 23, 2017, at 1:44 PM, Guillaume Lessard via swift-evolution > wrote: > > There is no clean way to use atomic operations in Swift at the moment, even > less so after most of OSAtomic.h was deprecated in Sierra. Of course, the > OSAtomic calls were never available in Linux, so there ar

Re: [swift-evolution] Analysis of existing scopes

> Le 23 févr. 2017 à 14:59, Matthew Johnson a écrit : > > The rationale for this is that it allows you to explore the eventual design > of a type without exposing it. When you are confident in the design all you > need to does modify the access modifier of the type itself. Without this > ca

Re: [swift-evolution] Analysis of existing scopes

> Le 23 févr. 2017 à 20:48, Matthew Johnson a écrit : > > Sometimes APIs are used internally in production while eventually planned for > public visibility. New features in Apple’s frameworks often start life this > way. Hmmm. In my experience, if I wanted to experiment with something in the

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 21, 2017, at 8:18 AM, Joe Groff wrote: >>> >> >> Yeah but Rust has a macro system so error-chain makes re-wrapping trivial. A >> simple `chain_err(|| “my new error message”)` is enough to define and >> “throw” a new error that wraps the underlying error. > > That was my point—they r

[swift-evolution] [Pitch] Allow trailing argument labels

Hi everyone, this is my first post, hopefully I get the formatting and everything right... > why not just require a leading dot, like an enum, rather than a colon? > less syntax to learn, and it still eliminates the extra type. I think this could lead to ambiguity if the trailing argument label wa

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

This is clean, but given knowledge of foo(bar:) syntax, its discoverability is low. Conversely, given knowledge of `foo()`, the discoverability of foo(bar:) would be low compared to `foo(bar:)`. If backticks were the *only* option, and also worked as `foo(bar:)`, the consistency would be appealing

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 23, 2017, at 2:04 PM, Ted F.A. van Gaalen > wrote: > > >> On 23 Feb 2017, at 02:24, Dave Abrahams wrote: >> >> Equally a non-starter. All known threadsafe schemes that require caches to >> be updated upon non-mutating operat

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Feb 23, 2017, at 10:40, Max Moiseev wrote: > > Conformance to Comparable is not required by anything in the standard library. That surprises me. Isn't there a sort function or something, or did we change it so they all need a predicate now? > I would argue that addi

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

I never liked the compound name syntax because parenthesis are deeply connected to the application of function, and it breaks with the way selectors are specified in Objective-C. If this topic is touched once again, imho it should be done thoroughly — with a syntax that can really eliminate all

Re: [swift-evolution] [Draft] scope-based submodules

Matthew, thank you for sharing this great text! Unfortunately was not able to read it in details yet, but after looking for proposed solution, have a quick question. You are proposing to have 'submodule' keyword in each file of that submodule. How can we then solve such issue: imagine that I h

Re: [swift-evolution] [pitch] Atomics

> On Feb 24, 2017, at 2:11 PM, Joe Groff wrote: > > The only way you can make atomics sort-of-work in Swift today is by > performing atomic operations on manually-allocated memory, since Swift > doesn't provide the necessary control over any memory the language manages to > get the guarantees

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Some very good points. But I’ll concentrate on what I disagree on to see where we can go from there. > On 23 Feb 2017, at 22:56, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Introduction > > There has been a deluge of discussion about access levels lately, all > attempting to sim

Re: [swift-evolution] [Draft] scope-based submodules

> On Feb 24, 2017, at 3:56 PM, Vladimir.S wrote: > > Matthew, thank you for sharing this great text! > Unfortunately was not able to read it in details yet, but after looking for > proposed solution, have a quick question. Thanks for taking a look! I’m looking forward to more feedback later.

Re: [swift-evolution] Strings in Swift 4

Hi David & Dave can you explain that in more detail? >> Wouldn’t that turn simple character access into a mutating function? assigning like s[11…14] = str is of course, yes. only then - that is if the character array thus has been changed - it has to update the string in storage, yes. but

Re: [swift-evolution] [Draft] scope-based submodules

> On 24 Feb 2017, at 20:34, Matthew Johnson via swift-evolution > wrote: > > I didn't expect submodules to be a part of the Swift 4 discussion. When it > came up I was pleasantly surprised. I have been thinking about the design of > a submodule system for quite a while but was planning to w

Re: [swift-evolution] Strings in Swift 4

Hi Dave Thanks for your time to go in to this an explain. This optimising goes much further then I thought. > That's fine. Please don't be offended that I don't wish to argue it further. > It's been an interesting exercise while I'm on vacation and I hoped it would > lay out some general princip

Re: [swift-evolution] Strings in Swift 4

> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen wrote: > > Hi David & Dave > > can you explain that in more detail? >>> Wouldn’t that turn simple character access into a mutating function? > > assigning like s[11…14] = str is of course, yes. > only then - that is if the character array thu

Re: [swift-evolution] [Draft] scope-based submodules

> On Feb 24, 2017, at 4:57 PM, David Hart wrote: > >> >> On 24 Feb 2017, at 20:34, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I didn't expect submodules to be a part of the Swift 4 discussion. When it >> came up I was pleasantly surprised. I have

Re: [swift-evolution] Strings in Swift 4

ok, I understand, thank you TedvG > On 25 Feb 2017, at 00:25, David Sweeris wrote: > > >> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen wrote: >> >> Hi David & Dave >> >> can you explain that in more detail? Wouldn’t that turn simple character access into a mutating function? >> >> ass

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Conformance to Comparable is not required by anything in the standard library. Besides, it is always possible to further constrain your own code as in: func f(_ x: T) where T.Magnitude : Comparable {} I would argue that adding constraints without solid proof of them being useful and necessary i

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >> >> Conformance to Comparable is not required by anything in the standard >> library. Besides, it is always possible to further constrain your own code >> as in: >> > > Besides Floating

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other F

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

I don't have a good answer for this, but I'll vote against 'foo(:)' because that's what a lot of people think the name of 'foo(_:)' should be. I'd rather be able to offer fix-its for that even when you have both 'foo()' and 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny ambiguit

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Whoops, after hitting Send I realized that I don't want to kill references to non-member functions, which means it's still useful to have a syntax for this. Still, there is one simple and unambiguous spelling when you need it… { foo() } trollface.gif, Jordan > On Feb 24, 2017, at 15:56, Jorda

[swift-evolution] [Pitch] Allow trailing argument labels

I'm not at all convinced ambiguity is a real problem, in this case. The event of this realistically being ambiguous is as unlikely as two otherwise identical functions accepting two different enum types, as well as those two enum types sharing a particular case name. This just doesn't happen in g

Re: [swift-evolution] Setting expectations on when we move to Discourse

Heh, that was just a flutter on the server. Thanks for reaching out yesterday, and sorry it wasn't resolved sooner. > On Feb 24, 2017, at 10:20, Adrian Zubarev via swift-evolution > wrote: > > Hi Ted, > > Is that the reason why the mailing list was down for 24 hours? > > > > > -- > Adri

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 14:44, David Sweeris wrote: > > >>> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: >>> >>> >>> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >>> >>> Conformance to Comparable is not required by anything in the standard >>> library. Besides, it is always possible to f

[swift-evolution] [Pitch] Allow trailing argument labels

Sorry, that turned into a bit of a rant, though hopefully a constructive one. I wasn't directing this at you in particular; I just wanted to properly get those points across. Begin Message Group: gmane.comp.lang.swift.evolution MsgID: <6407ad53-03ce-46a4-81a7-18e5c329

[swift-evolution] [Draft] Package Manager Manifest API Redesign

Hi all, Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a Package.swift manifest API redesign for the Package Manager. We'll welcome comments or discussion at this time. My hope is that we can get this polished up and ready for evolution within the next week or so, but

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

That was a deliberate design choice discussed during review of floating point protocols. Floating point remainder and integer modulo are very different. Spelling them the same way enables use in generic protocols, which would be incorrect uses. This was borne out by observation of erroneous uses of

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 24, 2017, at 4:45 PM, Xiaodi Wu wrote: > > That was a deliberate design choice discussed during review of floating point > protocols. Floating point remainder and integer modulo are very different. > Spelling them the same way enables use in generic protocols, which would be > incorr

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> Sorry, that turned into a bit of a rant, though hopefully a constructive one. > I wasn't directing this at you in particular; I just wanted to properly get > those points across. No worries at all, we're all working towards the same goal here. While I agree that the current proposals feel hea

Re: [swift-evolution] Analysis of existing scopes

On Fri, Feb 24, 2017 at 3:32 AM, Joanna Carter via swift-evolution < swift-evolution@swift.org> wrote: > > > Le 23 févr. 2017 à 20:48, Matthew Johnson a > écrit : > > > > Sometimes APIs are used internally in production while eventually > planned for public visibility. New features in Apple’s fr

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Thanks for the feedback David, The whole design and motivation behind SE-0117 is that it is not rare to > want classes to be freely subclass-able internally while being closed to > subclassing externally. Do you have arguments to contradict the lengthy > points mentioned in the SE-0117 motivation

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Before I start revising this proposal, there are a couple of open questions I’d like to discuss with the community and the core team. The first question relates to the purpose of having a “internal” argument name. There are applications of such names in GADT (if we ever get there) and perhaps t

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > The prevailing view from recent discussions is that there should be just one > access level more fine-grained than ‘internal’, and it should be spelled > ‘private’. Let us leave aside for the moment what

[swift-evolution] [Accepted] SE-0154: Provide Custom Collections for Dictionary Keys and Values

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md Hello Swift Community, The review of SE-0154 "Provide Custom

Re: [swift-evolution] Strings in Swift 4

Ted, It might have helped if instead of being called String and Character, they were named Text and ExtendedGraphemeCluster. They don’t really have the same behavior or functionality as string/characters in many other languages, especially older languages. This is because in many languages,

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Very well written. Personally I am in favor of very simple systems and to put the responsibility for an application by the application developer (not a library developer). Though I understand that in some cases (Apple!) the developer is the end-customer, and this creates special circumstances w