Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Tue, Jan 16, 2018 at 6:31 PM, Xiaodi Wu wrote: > On Tue, Jan 16, 2018 at 4:30 PM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> The thing that is “broken” here is generic programming. If I constrain >> something to FloatingPoint, I cannot use a float literal in calc

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

The thing that is “broken” here is generic programming. If I constrain something to FloatingPoint, I cannot use a float literal in calculations with it: func centimeters (inches: T) -> T { return 2.54 * inches// Error } Of course, “T: FloatingPoint” is an overconstraint in this example,

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

I should have been more clear: APIs that we add through Swift Evolution would continue to be permanent additions to the language just as they are today. I was not suggesting otherwise. However, the underlying behind-the-scenes ABI-related aspects of their implementations would initially be malleabl

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 11:27 PM, Xiaodi Wu wrote: > On Mon, Jan 15, 2018 at 20:37 Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> >> That protocol is spelled ExpressibleByFloatLiteral, which reflects the >> meaning that we want and should have. The name is correct, the

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Mon, Jan 15, 2018 at 8:51 PM, Xiaodi Wu wrote: > On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > >> All I’m saying is the current situation seems semantically wrong. As in, >> how can a type claim to be a floating point number, if it *litera

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

Jan 15, 2018 at 4:24 PM, Nevin Brackett-Rozinsky via > swift-evolution wrote: > >> Currently, the FloatingPoint protocol does not conform to >> ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does. >> >> The only explanation I can find for this is a brief comm

[swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

Currently, the FloatingPoint protocol does not conform to ExpressibleByFloatLiteral, whereas BinaryFloatingPoint does. The only explanation I can find for this is a brief comment from Steve Canon during the review

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

Alternatively, from a different perspective, rather than adding a new ABI-unstable library that gets bundled with apps, another way to look at it is that we already *have* an ABI-unstable library that gets bundled with apps. So we can instead think about introducing a new library with a stable ABI,

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

This is not an optional-chaining issue *per se*. If you simply write, let a = try? SomeType().doThrow() // a has type SomeType?? you get a double-optional as well. Are you proposing to change that? Nevin On Fri, Jan 12, 2018 at 12:25 PM, Russ Bishop via swift-evolution < swift-evolution@swift

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

On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote: > I agree. > > If there should be an API to produce a random Double without parameters > then IMHO it should simply be a uniformly distributed Double in the unit > range [0, 1). Very useful as a b

Re: [swift-evolution] Incremental ABI stability

n Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > > I’m just spitballing here, and I’m not an expert on matters

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

On Tue, Jan 9, 2018 at 9:27 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > I think this type might become more useful if we find a good name for it > and better document it. For example, it is a natural fit for parameter list > of Chris’ callable type proposal. > > Since

[swift-evolution] Incremental ABI stability

I’m just spitballing here, and I’m not an expert on matters of ABI, however the thought occurs to me that the current all-or-nothing approach might lead to suboptimal results. In particular, some recent discussions on this list have mentioned that certain parts of the standard library, such as Mir

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

On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com < charlesism@gmail.com> wrote: > I used a DictionaryLiteral only yesterday, and it turned what would have a > typically unreadable array of Structs into something much more elegant. I'm > pretty sure the only reason Literals (of all variet

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

On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Thank you for the clarification. It occurred to me in the shower that this > might be the case, and that I was entirely mistaken as to what we were > talking about. > > Yes, then, I wholeheartedly

Re: [swift-evolution] DynamicMemberLookup proposal: status update

There’s a lot of information here and it’ll take some time to process it all. My initial reaction is that a “strong type-alias” feature might help. If one could write (strawman syntax): strong typealias Dog = PyVal// A semantically independent new type extension Dog { // Declarations here

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

On Thu, Jan 4, 2018 at 8:23 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 3, 2018, at 10:02 AM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > > 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on > externall

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

On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming th

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

On Tue, Jan 2, 2018 at 12:47 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > 1) When dealing with independently updated binary packages, your code > *has* to implement some behavior for unexpected cases if the enum is > non-exhaustive. It isn’t acceptable to not han

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

Making enums non-exhaustive solves a problem for authors of precompiled frameworks which apps can dynamically link against. These libraries need to preserve binary compatibility, in the sense that apps should continue to work with newer versions of the library. Now, that creates a problem for app

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

On Wed, Dec 20, 2017 at 10:01 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > > I have been doing the unkosher thing of using these underscored attributes > and would very much like to see these formalized. > > My one bikeshedding issue here is the name @abiPublic, which sme

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

If we’re bikeshedding the verb tense then “compactMap” sounds right to me, and adding “ing” would be needlessly verbose. For the non-mapping version, I’d lean toward “compacted”. However, we could also postpone the debate over its spelling until such time as we are actually ready to introduce it.

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

I have no input on whether or not this dynamism should be added to Swift. However, *if* we add it, then I strongly prefer that dynamic member lookup should use the exact same syntax as static member lookup, namely a single dot. Member lookup is member lookup, the user-facing behavior is the same i

Re: [swift-evolution] [RFC] Associated type inference

On Thu, Nov 30, 2017 at 7:28 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > *A Rough Proposal* > I’ve been thinking about this for a bit, and I think there are three ways > in which we should be able to infer an associated type witness: > > >1. Associated type def

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

On Tue, Nov 28, 2017 at 1:05 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > To close the loop here, the core team has agreed to this as an amendment > to SE-0143, and the changed has been merged here: > > https://github.com/apple/swift-evolution/pull/769 > > and we’

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

The proposal mentions one reasonable situation where a larger-than-Int type would be useful, namely a Collection wrapping a memory-mapped file, being used on 32-bit systems. Is there a recommended migration strategy for this scenario? Nevin On Mon, Nov 27, 2017 at 8:34 PM, Douglas Gregor via sw

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

Without commenting on anything else, I have encountered one use-case where it would be nice to be able to “call” an instance. And that is, while modeling some mathematics, I made a DifferentiableFunction type which stores a function and optionally a reference to another DifferentiableFunction (its

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

On Wed, Nov 15, 2017 at 8:05 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > “unwrappingMap”(or some variations using unwrap). > I’d like to propose “mapAndUnwrap”. It does what it says on the tin: map a sequence (into an optional type), then unwrap the values which exist.

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

On Sun, Nov 12, 2017 at 10:16 PM, Slava Pestov wrote: > > Pardon my lack of imagination, but could you provide an example of a call > site that would become ambiguous? > > > protocol P {} > protocol Q {} > struct S : P, Q {} > > struct Outer { > static func foo(_: P) {} > > struct Inner { >

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov wrote: > Yeah, this is an unfortunate wart. Right now unqualified lookup starts at > the innermost scope and stops when it finds a candidate which matches the > name being looked up. Overload sets are only formed if there are multiple > candidates ins

[swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

I brought this up on Swift Dev and was told to check on Swift Evolution to see if a proposal is needed. Currently, the following code produces a compiler error: func foo(_ x: Int, _ y: Int) -> Int { return x + y } extension Int { func foo() -> Int { return foo(self, self)// Error her

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] 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] 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] 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] 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] 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] 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] [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

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] 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] 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

[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

[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

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

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 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] [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] 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] 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] [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] [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] [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] 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] [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] [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] 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] 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

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 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

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] [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] [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] 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-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] [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] [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-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] [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] [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] [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] 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] 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] 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 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 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

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 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] [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] [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] [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

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] 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] [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] [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] [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] [Draft Proposal] Improve protocol inheritance behaviour

The way I want things to work, “super” always calls the superclass’s method with matching name and signature. For the scenario you outlined, the superclass defines such a method, so it gets called. For the situation relevant to this proposal, if the superclass *obtains* such a method via default i

Re: [swift-evolution] [Draft Proposal] Improve protocol inheritance behaviour

Also, you don’t have to go through a superclass method to see the problematic behavior. You can simply use a subclass instance in a variable of superclass type: let subclass: MyClass = MySubclass() subclass.doTheSecondThing() // Prints “The 'DEFAULT' 2nd method” Nevin

Re: [swift-evolution] [Draft Proposal] Improve protocol inheritance behaviour

I agree there is a problem here, and the mental model I want is for the language to act “as if” the default implementation of the protocol requirement “had actually been” implemented by each type which uses it. In particular, if a class uses a default implementation for one of its protocol require

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

On Fri, Mar 10, 2017 at 4:16 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > I’m ok with doing it as an extension on `Comparable`, although we should > add an overload for regular ranges, too. > > - Dave Sweeris > How would the semantics of that work? Should “16.cla

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

I’d be on board with an extension of Comparable so you could write “16.clamped(to: 0...10)”. Something along the lines of: extension Comparable { func clamped(to range: ClosedRange) -> Self { return max(range.lowerBound, min(self, range.upperBound)) } } Nevin _

Re: [swift-evolution] [Draft] Fix Private Access Levels

I support this proposal to restore the file-based meaning of “private”. Personally, I do not think we need any more fine-grained access level than this, so I lean toward solution 1 (remove the scoped access level). However, I would also be okay with solution 2 (rename the scoped access level to sc

[swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

This is an intriguing proposal. There are parts I like, and parts that I will have to think about more before drawing an opinion. Personally, I would like to see public classes be inheritable, public protocols be conformable, and public enums be switchable, unless specified otherwise. However I wi

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

One use-case that springs immediately to mind is creating ranges of magnitudes. It is not sufficient to use abs() because that returns the same type which may not be comparable. Also, a fairly common operation on complex numbers (or indeed any metric space) is to see if two values are within dista

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

Also not core team, but I didn’t realize this was missing during the review. If I had I would have spoken up, because mathematically a magnitude is *defined* as something that can be compared to see which underlying object is bigger. It is a measure of size, and it exists so that the sizes of obje

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

Rien, your example shows two things (well, three, but one relates to variadic arguments not access levels). First, it shows the importance of being able to prevent external overrides of individual methods. I did not directly address that in my pitch, however it could easily use the same syntax as

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

I think the most important goal is to end up with the right set of operator and identifier characters for *Swift*. The Unicode guidelines are a useful tool for that purpose, and get us a long way toward where we want to be. However at the end of the day we should weigh our success by how well we ha

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

This looks very good Xiaodi, and I have a few thoughts about it. First, is the intent that Swift will follow future changes to Unicode operator recommendations, or that Swift will choose a “frozen in time” set of Unicode recommendations to adopt? If the former, then we will likely see source-break

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

[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

  1   2   >