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

I strongly prefer that “private” should mean “visible in the current file”. I am ambivalent between eliminating the scoped access level or renaming it “scoped”, as long as “private” once more denotes file-level visibility. Nevin ___ swift-evolution mail

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

On Sun, Mar 26, 2017 at 12:57 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 26, 2017, at 08:50, David James via swift-evolution < > swift-evolution@swift.org> wrote: > > I propose instead that we revise to use Alternative #3, per Vladimir’s > comment and revi

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

On Mon, Mar 27, 2017 at 1:47 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > Creates a mechanism that actually makes sense for what people are using > ‘exten

Re: [swift-evolution] [Pitch] String revision proposal #1

On Thu, Mar 30, 2017 at 3:39 PM, Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > > > (for instance, mathematical sets may contain anything at all, including > themselves) Well actually they can’t , for…reasons

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

For “all(equal:)” I think there should be no argument label. We can already write “nums.contains(9)”, so if we add “all” then we should be able to write “nums.all(9)”. Other than that, I like the idea. Nevin ___ swift-evolution mailing list swift-evolut

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

If indeed “all(equal:)” is rarely needed, then perhaps it is best to leave it out *and also* leave out the argument label from “all(matching:)”. Then the signature would be similar to, func all(_ predicate: (Element)->Bool) -> Bool and the points-of-use would look like: nums.all( isEven ) nums.a

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I don’t think it is worth our collective effort to bikeshed this right now. The feature might be nice, but it is a small thing that is easily done without. Since we know that naming things is one of the two hard problems in computer science , I thin

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

I am greatly disappointed by this decision. The existence of the keyword “fileprivate” is an unfortunate blemish which never should have been brought into existence. In my view, the churn caused by renaming “private” last year was a major mistake, and we should correct it immediately. I hope the c

Re: [swift-evolution] Type-based ‘private’ access within a file

On Mon, Apr 3, 2017 at 8:26 PM, Jarod Long via swift-evolution < swift-evolution@swift.org> wrote: > Pretty bummed out about the rejection. I know it's a petty aesthetic > issue, but thinking about having to write "fileprivate" 5 or 10 years from > now kills more of my enthusiasm about using the l

Re: [swift-evolution] Type-based ‘private’ access within a file

As I see it, this new proposal misses the mark in both directions. It does not replace file-level visibility, because extensions of external types wouldn’t be able to work with private declarations in the same file. And it throws out a major use-case of scope-based access, which is to ensure that i

Re: [swift-evolution] Type-based ‘private’ access within a file

On Tue, Apr 4, 2017 at 3:30 PM, David Hart wrote: > I agree with you. But that soft-default requires a simple and recognisable > name. That’s why I proposed SE-0159. But it got rejected. If we accept that > fact, this proposal now attempts to give private back its original intent > as a soft-defa

Re: [swift-evolution] Type-based ‘private’ access within a file

On Tue, Apr 4, 2017 at 10:00 PM, Brent Royal-Gordon wrote: > > There *may* be gains to be made by a ` `private` -> `scoped`/`fileprivate` > -> `private` switch (I'm skeptical, but I can see the argument), but that's > not in the offing, either. > For myself (and I suspect for many others) the fi

Re: [swift-evolution] Type-based ‘private’ access within a file

On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > - fileprivate should really become much more rare, which makes it more > meaningful and significant where it occurs. This was the original idea and > intent behind SE-0025. > I would like

Re: [swift-evolution] Type-based ‘private’ access within a file

On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > We accepted SE-0025, though I wish we hadn't; we named the two levels > "private" and "fileprivate", though I wish we hadn't; and now there is lots > of existing code relying on that, and it wou

Re: [swift-evolution] [pitch] One-sided Ranges

Strong +1, glad to see this happening! Nevin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

In order to evaluate this proposal, I created a table of as many relevant scenarios as I could think of, and listed how each of the proposed solutions would work there. The four access level systems I compared are: *No change:* The existing Swift 3 *status quo* with “fileprivate” and “private”. *

Re: [swift-evolution] [pitch] Comparison Reform

Another option is to make a new type, not sure what to call it but I’ll use “Num” for now, that is essentially the same as Double except it does not represent NaN. After all, why should a numeric type ever be “not a number”, and what sort of name is “Double” anyway except as a hold-over from legacy

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

All right, time to dive in! First things first, the “helper visible” row in the table I posted is actually unnecessary: a private helper type can have its visible members unmarked (so, “internal”) and they will be available throughout the file. Now, if we believe that cross-type sharing ought be

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

On Mon, Apr 17, 2017 at 4:52 PM, Tino Heth <2...@gmx.de> wrote: > > the only way to hide one invariant from the other’s methods is to use > helper types > > Could you elaborate here and give an example that uses such helper types? > Okay, let’s say we have a type Foo with a String property and a

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

I am glad that “private” will become usable again in Swift 4. This eliminates most of the pain caused by “fileprivate”. However, I do not understand why this solution was chosen over renaming the keywords. The discussion of alternatives here does not mention it, and the only explanation given afte

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

> > >- What is your evaluation of the proposal? > > Strong +1, especially for the unary operators. They make code clear, concise, and elegant. Pattern matching against one-sided ranges looks great, and being able to use postfix “...” to create a sequence is niche but nifty. > >- Is the p

Re: [swift-evolution] [Review] SE-0174: Change `filter` to return an associated type

Another possibility is to make “map” generic on the return type, something like: extension Collection { func map (transform: (Iterator.Element) throws -> T.Iterator.Element) rethrows -> T { var result = T() for e in self { try result.append(transform(e)) } return result

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

On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon < > br...@architechies.com> wrote: > >> I would think only final classes could participate in this, since a >> subclassable class would need to al

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

On Sun, May 7, 2017 at 2:04 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Actually, `swapAt` does have a precondition that the elements differ. Looking at the source code , the “swapA

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

Looks good at first glance. Is there a diff showing what’s changed though? Nevin On Thu, May 11, 2017 at 5:39 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift Community, > > The review of SE-0163: "String Revision: Collection Conformance, C > Interop, Transc

Re: [swift-evolution] Revisiting SE-0110

One possibility is to make parentheses consistently meaningful in closure argument lists, so that “(a, b)” would exclusively mean “there is one parameter of tuple-type, which is being destructured”, while “a, b” without parentheses would exclusively mean “there are two parameters”. That way you ca

Re: [swift-evolution] Revisiting SE-0110

On Sun, May 28, 2017 at 7:04 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > We need to add back tuple destructuring in closure parameter lists because > this is a serious usability regression. If we're reluctant to just "do the > right thing" to handle the ambiguity o

Re: [swift-evolution] Revisiting SE-0110

the very outermost parentheses around the entire parameter list of the closure which should be optional. Nevin On Mon, May 29, 2017 at 1:32 PM, Vladimir.S wrote: > On 29.05.2017 18:26, Nevin Brackett-Rozinsky via swift-evolution wrote: > >> On Sun, May 28, 2017 at 7:04 PM, John McCa

Re: [swift-evolution] Revisiting SE-0110

On Mon, May 29, 2017 at 3:18 PM, Vladimir.S wrote: > On 29.05.2017 21:08, Nevin Brackett-Rozinsky wrote: >> >> barTuple{ (x, y) in } // valid, destructuring one tuple >> barTuple{ ((x, y)) in } // valid, destructuring one tuple with optional >> parentheses >> > > Here is the problem for me. Acc

Re: [swift-evolution] Revisiting SE-0110

On Mon, May 29, 2017 at 10:47 PM, Robert Bennett wrote: > I think the goal of SE 0110 and to a lesser extent 0066 was to disallow > this level of intelligence in the compiler. > Interesting. I happen to think that the goal of SE–110

Re: [swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

Yay! ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Object aliases

This sounds similar to lenses. Have you looked at previous lens discussions on-list? Nevin On Fri, Jun 23, 2017 at 3:28 AM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > I started a thread earlier this week about strong type-aliases and object > aliases. Here’s a fulle

Re: [swift-evolution] [pitch] composition as part of the language

This sounds similar to automatic protocol forward, have you looked into prior discussions on that topic here? Nevin On Thu, Jun 22, 2017 at 10:56 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > Let's take a quick look at how we can achieve very simple compile-time > com

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

The updates look fine and reasonable to me. That said, I think it is highly important that we have clarity regarding what *is* the proper time, method, and process for raising issues with and suggesting modifications to approved proposals. If there is one thing we have learned recently it is that

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

I think fixed-size arrays should be a nominal type like any other. They should be able to have methods, conform to protocols, be extended with new behavior, and generally present a user-experience similar to what arrays already have. In particular, they should conform to Collection and to Expressib

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Looks good to me, though I have some clarifying questions. For a type which conforms to both Equatable and Hashable: 1. To automatically derive both Equatable and Hashable, will it be sufficient to declare “struct Foo: Hashable” (since Hashable refines Equatable) or must “Equatable” also be listed

Re: [swift-evolution] private extension

I agree this should be considered a simple bug. Have you filed a bug report? Nevin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private extension

I counter with the rationale for rejecting SE-0119 , namely: The review of "SE-0119: Remove access modifiers from extensions" ran from > July 12...19. The proposal has been *rejected*. > > The majority of the feedbac

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

I am really glad this is happening, it will make implementing basic data types much nicer, and it is exactly the sort of feature that saves developers from having to waste time thinking about trivial rote boilerplate both when writing and when reading code—an excellent and welcome addition to the l

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

On Wed, Sep 6, 2017 at 5:42 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > the issue I'm trying to raise is that when those, and similar features, > are used in synthesised behaviour (default implementations based upon the > concrete type), that these behaviours should be o

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

Tony makes an excellent point, and I agree. At some point in the future we should consider introducing a “transient” attribute for caches and other non-essential properties. That will make generated conformances more powerful while simultaneously reducing boilerplate. Nevin On Tue, Sep 12, 2017

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

On Wed, Sep 13, 2017 at 2:47 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > > > As was noted in this thread, some people believe that protocol > synthesizing its requirements by accessing type's fields is of a different > kind than 'usual' protocol with default implementat

[swift-evolution] Different types for getter and setter

This may sound rather strange in the abstract, but recently I have encountered two situations where I would like to have a setter that accepts a different type than the getter returns. In the first, the getter returns Foo and the setter should accept “@escaping @autoclosure () -> Foo”, so that the

[swift-evolution] Retroactive protocol inheritance

With Swift 4 out, I’ve started using the numeric protocols quite a bit, and they are great! One thing I find myself wishing for is a protocol that extends Numeric while also allowing division—a Field protocol, if you will. I have implemented several algorithms generically over FloatingPoint becaus

Re: [swift-evolution] Re-pitch: remove(where:)

I think it is worth considering a version which both removes items in place, and also returns the removed items, so as to split the collection by a predicate. Nevin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailma

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

I am hugely in favor of an @inlinable attribute, and I look forward to its arrival with relish! Some feedback: 1. I think “inlinable” is the right spelling: it indicates that something is *able* to be inlined. 2. If I want to pass an @inlinable function as an argument (say, to map or filter) can

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

On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov wrote: > Thanks for taking a look! > > > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > > 3. Even though @inlinable will have no effect on declarations which are > not public, we should still allow it

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

I rather suspect that we would be best served by starting with integer literals as the only accepted “values in generics”. This would let us define fixed-size arrays and matrices, the modular arithmetic types you describe, and several other mathematical entities. Nevin. ___

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

017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov wrote: >> >>> Thanks for taking a look! >>> >>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky &l

Re: [swift-evolution] superscripts, subscripts, etc.

On Tue, Oct 3, 2017 at 2:02 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > You want: > > x² to parse as “superscript2(x)” - not as an identifier “xsuperscript2” > which is distinct from x. > > -Chris I am of two minds on this. Sometimes I want x² to parse as x*x (an

Re: [swift-evolution] Property Getter Return Statement

+1 We don’t need “return” in single-line closures where the type is known, and I don’t see why it is required in single-line getters. Nevin On Sat, Oct 7, 2017 at 10:07 AM, James Valaitis via swift-evolution < swift-evolution@swift.org> wrote: > Is it widely agreed that it is necessary to requ

Re: [swift-evolution] Property Getter Return Statement

On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu wrote: > This has been brought up on the list before. For instance: > > https://github.com/apple/swift-evolution/pull/608 > > Chris Lattner’s response at that time was: > > ‘Just MHO, but I consider this syntactic sugar, not a fundamental feature > that

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter. I would summarize the points on both sides as follows: For the change: • It is surprising to many people that members of a private extension are im

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

I believe Kelvin was asking about the usage of ellipsis *by itself*, as in Xiaodi’s example, “newBuffer[...]”. Nevin On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution < swift-evolution@swift.org> wrote: > ICYMI, SE-0172 was the proposal of one sided range and it has been > implemen

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > Yes, a 0-ary operator like that would have to be hard baked into the > language itself. > Actually, you can just make a subscript which takes a function as an argument, and call it by passing in th

Re: [swift-evolution] Optionals and nil in Switch statement

Does `case "text"?` work? On Tuesday, June 28, 2016, Kevin Nattinger via swift-evolution < swift-evolution@swift.org> wrote: > Case .none: > Case .some("string"): > > > On Jun 28, 2016, at 06:40, Lucas Jordan via swift-evolution < > swift-evolution@swift.org > > wrote: > > Forgive me if this was

Re: [swift-evolution] Optionals and nil in Switch statement

I just got home and tested. The answer is yes, `case "text"?` does work. let optStr : String? = "text" switch optStr { case nil : print("Nil") case "text"? : print("Success") default : print("Default") } // Prints `Success` Nevin On Tue, Jun 28, 2016 at 12:27 PM, Nevin Brackett-Rozinsky

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

I’m glad this was approved, the improvements look substantial! My one question is why are the bitwise operations (and/or/xor) modeled as member functions rather than operators? On Thursday, June 30, 2016, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: >

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

On painting the relative-precedence bikeshed, I would lean slightly toward “before” and “after”. They are short, single words with unambiguous meaning. Moreover, the actual point of interest is “Which operators will be evaluated before which other ones?” Plus the word “precedence” itself connotes

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

The incomplete range concept is quite intriguing. Have we considered spelling the operators with an asterisk at the incomplete end? prefix *..< prefix *... postfix ...* postfix ..<* That way the use-sites would look like: someCollection[*..From a “first-glance” perspective, the asterisk “looks li

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation. Nevin On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 01 2016, Riley Testut wrote:

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

How about Syntax.IntegerLiteralDestination as a name? That way just as, for example, CustomStringConvertible can be read to mean “This type can be converted to a string in a custom manner”, we would have Syntax.IntegerLiteralDestination meaning “This type can be the destination for a literal integ

Re: [swift-evolution] Optional comparison operators

Regarding the spelling of optional promotion, I think “postfix ?” could be a solution. Notably, it already works in pattern matching (see the first two case conditions here): let anInt = 16 let anOpt = Optional(anInt) switch anOpt { case 2? : print("Deuces") case anInt? : print("Huzzah") default

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

I concur with Joe Groff and John McCall, this proposal does not seem to be the right approach. What I would really like is the complete elimination of implicit coercion to Optional (implicit type conversions are not Swifty!) and the simultaneous introduction of a simple notation for doing so expli

Re: [swift-evolution] Nested for-in loops syntax

I think this use-case is too narrow for dedicated syntax in the standard library. However, it should be simple enough for you to write your own function, let’s call it `unpack`, which produces a sequence that does what you want. While you’re at it you could also try writing a `cross` function tha

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

My understanding is that “being able to change access levels by simply flipping a switch on the type itself” is a positive goal of Swift. Therefore, it emphatically *should* be allowed to set the default visibility for an extension the same as (or higher than!) the type it extends. For example, a

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

> > Now if the struct’s visibility is changed, each extension member will be > accessible up to the maximum availability of the type, the extension, and > itself. …I of course meant “minimum” here. Nevin On Mon, Jul 18, 2016 at 12:25 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.c

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I remember it differently. The opposition to SE-0119 “Remove access modifiers from extensions” was primarily because the proposal itself was malformed and, to quote you from the review thread, “doesn’t do what it says on the tin (aka in the title)”. In that thread Jordan Rose said “the proposal is

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Garth makes an excellent point. Károly is correct that we can already achieve “sealed” by making a `final` member call through to an `internal` one. Therefore, it seem clear that “open” should only be applicable to classes, not to members. This should simplify the proposal nicely. Nevin On Mon,

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

I’ll concur with Jose: Either replace parens with square brackets so the declaration of a subscript matches its point of use (in which case a colon would be acceptable) or else leave it as it is. I am (-1) on the proposal as written, (+1) on square brackets for subscripts (with either colon or ar

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> > However, once we've got non-open public classes — and as I understand it, > you still support those — that complexity already exists. You're not > really eliminating anything by preventing this from being applied to > methods. We may not need to prevent public members from being declared non

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

On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > Mathematical correct or not: > > in case of > s1.hasPrefix(s2) > (or any other containment test method) > > s1 and s2 are just plain simple instances of String, > no

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> > *What is your evaluation of the proposal?* Strong +1 to either design, and neutral between them. In the prior review I advocated that `open` should *only* apply to classes, not members. This new proposal turns that on its head and is *vastly superior*. Tagging open members with *just* the wo

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> > I agree that it would make sense to be able to say "I allow subclasses, > but they > don't get to override any of my methods unless I say so, even things I > inherit". > But that feels like a refinement. Well, we can already achieve that by writing, public final func f() -> Int { return _f

Re: [swift-evolution] [Proposal] Struct syntax for requesting a copy with an ivar set to an explicit value

As an additive proposal this is out of scope for Swift 3. Discussion of additive proposals resumes August 1. This functionality has been discussed on-list before, especially regarding a global “with” function. I believe Erica Sadun has a particularly elegant implementation. Nevin On Thu, Jul 21

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> > All of these nits would just go away if open were an access level. Again, > all of this is the case because open *really does* quack like an access > level and walk like an access level. +1 Well-said Garth. Nevin On Thu, Jul 21, 2016 at 6:29 PM, Garth Snyder via swift-evolution < swift-ev

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

Excellent point Karl. In my view, floating point NaN values are really quite similar to `.none`. I would be interested in exploring a move *away* from the IEEE 754 handling of NaN. In particular, we could model Float and Double as optionals (maybe implicitly-unwrapped) with NaN bit-patterns indic

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

Another option would be to leave the IEEE 754 NaN hijinks in Float and Double (as numerics people expect), and create a new type (with a nice approachable name) that “acts like” Double but does not model NaN. Then any operation which would ordinarily produce a NaN, instead traps for the new type. T

Re: [swift-evolution] [Draft] Fix a typo in two String methods

And yet the *name* of the character is the “null character ”, and a string that terminates in one is called a “null-terminated string ”. Those are the terms of art, and I would not expect an abbrevia

Re: [swift-evolution] [Draft] Fix a typo in two String methods

I think the hypothetical alternative would be `nullTerminatedCString` for one and `nullTerminatedUTF8` for the other. Nevin On Sun, Jul 24, 2016 at 6:34 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

Pyry, this proposal looks great to me. My one question is, will I be able to write `someCollection.sort(.ascending)` and get the expected result? (This could be an additive future direction.) Stephen, what is your rationale for wanting `<=>` to identify NaN values with different payloads as `.equ

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

* What is your evaluation of the proposal? “It’s complicated” First, I agree with the prevailing sentiment that the incomplete-range portion ought to be separated and postponed. Second, the proposed renaming of methods brings great consistency. However, I believe that `first(n)` and `las

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> > * We considered using `first` and `last` as the basis for both >single-element and multiple-element operations (such that `prefix(3)` >would become `first(3)`, etc.), but: > 1. These seemed like distinct functionalities, particularly since > their types are different. I thi

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

Whoops, hit reply too soon. Please consider the following inserted in the gap in my last email: 2. We're not comfortable with heavily overloading a property with a bunch > of methods, and didn't want to make `first` and `last` into methods. I am okay with this overload precisely *because* the fu

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Tue, Jul 26, 2016 at 6:58 PM, Boris Wang wrote: > the single word “first” only means one element， > but “prefix” can means multiple element. > I dispute the former claim. As evidence I cite: • The first four letters of the alphabet are A, B, C, and D. • The first three Presidents of the Unit

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Tue, Jul 26, 2016 at 7:56 PM, Boris Wang via swift-evolution < swift-evolution@swift.org> wrote: > We should consider SE-0111. > The label of parameter is not part of function signature anymore. > What are you driving at? Per SE–0111

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> > The third review of "SE-0177: Allow distinguishing between public access > and public overridability" ran from Active review July 21...25. The > proposal has been *accepted with revisions*. The third review of "SE-0177: Allow distinguishing between public access > and public overridability"

Re: [swift-evolution] [Discussion] Breaking precedence

Speaking for myself, I will *never* remember which of `&&` and `||` has higher precedence. I think of them as peers, so I always use parentheses around them, and whenever I read code that mingles them without parentheses its meaning is *unclear* to me. One of Swift’s main goals is clarity at the p

Re: [swift-evolution] [Discussion] Breaking precedence

@Xiaodi Actually, I think just about all the rest of the precedence rules “make sense” intuitively: `a | b == c % d` `a < b ? c : d * e` `a ?? b - c` `a...b+c` These all do what they ought to, and of course assignment naturally has low precedence. Really the only confusing ones are operators that

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

A few things immediately spring to mind: • Fixed-size arrays • An optimized Matrix type • Swifty syntax for Fourier transforms • A numerical integrator (or diff-eq solver!) • BigInt capabilities The first of these (fixed-size arrays) will probably require compiler support. The rest can already be

Re: [swift-evolution] Class scoped access level

Indeed, I find it rather less convenient to write “fileprivate” in many places I previously would use “private”, and unfortunate that I must choose between aggregating many pieces into a single lengthy file or else polluting the module scope with implementation details. I agree with Xiaodi that su

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I think there is a deeper issue that may be worth exploring here. Notably, when one class presents a member function, its subclasses ought to use “override” when they reimplement that method themselves, regardless of where the superclass’s version comes from. In the original post, the class “A” e

Re: [swift-evolution] Mark protocol methods with their protocol

I have been following this discussion (as well as similar threads earlier this year) and listening to the ideas put forth by all sides. It seems to me that the fundamental difference between classes and protocols is that classes inherit implementation whereas protocol conformance is a promise abou

Re: [swift-evolution] class/struct inner member access scope classifier

Just to weigh in here, I too am enjoying Swift 3 greatly. However, my experience with access modifiers is rather different. I am very glad that `internal` is the default: this reduces extraneous noise for the common case, and makes it really easy for new programmers to jump in. Furthermore, I am

Re: [swift-evolution] class/struct inner member access scope classifier

In another thread (no link because we’re not on a forum ;-) the idea was raised that in the future, if and when Swift starts using submodules, the “fileprivate” scope could be turned into “submodule” scope. By default every file would constitute its own submodule, and developers could choose to pu

Re: [swift-evolution] [Pitch] Refactor Metatypes

Let me first say that this new draft does a great job of explaining the current situation and the goals of the proposal. The revised “Motivation” section in particular is very clearly written and introduces the concepts effectively. I found the previous versions to be highly confusing, and I did n

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

+1, I have been mildly surprised that this was not already present. My workaround heretofore has been: for idx in abc.indices { let val = abc[i] // do something with idx and val } Nevin On Wed, Sep 28, 2016 at 1:55 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

I like Sean’s idea. Nevin On Wed, Sep 28, 2016 at 2:34 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > This might just be me being silly, but is there any way to be able to do > something like this instead: > > for (index, value) in sequence { > } > > Maybe by adding ano

Re: [swift-evolution] [Pitch] Refactor Metatypes

>From Brent’s explanation, it sounds to me like “Type” and “StaticType” respectively would be more descriptive than “Subtype” and “Type” as proposed. Nevin On Thu, Sep 29, 2016 at 10:29 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Sep 29, 2016, at 3:24 P

Re: [swift-evolution] [pitch] replace (if/guard) case = with ~=

While we’re on the subject, has there been any discussion about adding a pattern matching operator with the polarity reversed? To me at least it seems far more natural to write, eg., “case x =~ somePattern” and to read it as “x matches somePattern” rather than the status quo “somePattern matches x

  1   2   >