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

> Also, while some have mentioned that this adds complexity to the access > control system because types are now a factor, to that I say: this is purely > a theoretical issue. In practice, developers don't care that this is case, > and just care that the access control logic makes sense when

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

>> And it's a style that is so widely used by the Swift community that even if >> you think it's a bad practice does not change the fact that many people use >> that style and that the current access level rules don't play well with them. > > Just because it’s widely used doesn’t mean it’s a

[swift-evolution] Turning access control into SEP ;-)

I don't remember the exact location, but there have been several contributions from active members of the community who stated they would be fine with just two levels of access control — but I haven't seen this standpoint discussed at all. Most likely, that is because it contradicts the

Re: [swift-evolution] Turning access control into SEP ;-)

I use this access control model. As I usually split large classes into multiple files using extensions, marking members "fileprivate" or "private" initially is pointless. Of course, "private" can be used for small classes which don't need to be split, but that would be inconsistent. Also the

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

Swift needs a datatype that contains a fixed number of a given type; basically a simple fixed-size array. Motivation: I’ve been porting code for Monte Carlo Tree Search in my Go-playing program from C++ to Swift. Performance is crucial for this code, as more simulations lead to better play.

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

On 17 Apr 2017, at 01:46, Riley Testut wrote: > > So while you personally may not use extensions, calling the use of them > "spaghetti code" is rather misguided IMO. You’re right, I overgeneralized. Let me correct myself: From what I’ve seen so far [*], using extensions

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 16.04.2017 0:22, Adrian Zubarev via swift-evolution wrote: Hi guys, I am, and also my English is, at my most limit fighting in this conversation. ;-) I would not support, v1 v2 and v3 at all and would wish these options to be completely banned for a nice and simple model, even if all of

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

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >>> > I have an incipient idea. It begins with: >> >> > >> >> > enum ComparisonResult { >> >> > case

Re: [swift-evolution] [Pitch] Adding safety to arrays

on Fri Apr 14 2017, Karl Wagner wrote: > Personally, the only valid use-case I can think of is when you want to > initialise an Array’s elements out-of-order - i.e., you want to set a > value for myArray[2] despite myArray[0] and [1] not being > populated. In that

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

> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution > wrote: > > For example, I expect `XCTAssertEqual(_:_:)` to be vended > as part of XCTest, in order to make sure that > `XCTAssertEqual(resultOfComputation, Double.nan)` always fails. Unit tests strike

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

> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution > wrote: > > >> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> For example, I expect `XCTAssertEqual(_:_:)` to be vended >> as part of XCTest, in

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

Hello Swift community, The review of SE-0172 "One-sided Ranges" begins now and runs through April 23, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md Reviews are an important part of the Swift evolution process. All

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

> On Apr 17, 2017, at 18:53, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > At a meta-level, since mistakes like SE–0025 will be much more costly in the > source-stable future, we ought to consider adding a step to the Swift > Evolution process whereby

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Simple: you put the user code that needs the more accurate library in one file and import only the more accurate library there, and you put the user code that needs the more performant library in a separate file and import only the more performant library there! Swift's devotion to file-based

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

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] Swift needs fixed-size array

> On Apr 17, 2017, at 12:37 PM, Karl Wagner wrote: > >> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution >> > wrote: >> >> Proposal: UnsafeMutablePointer almost provides what I need. However, it can

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

> You’re right, I overgeneralized. Let me correct myself: > > From what I’ve seen so far [*], using extensions for "code organization" > often results in spaghetti code. > > [*] Observed as a contractor; iOS platform; average Joe's code. Fair :-) Another use case for extensions I had

Re: [swift-evolution] [Pitch] Adding safety to arrays

> Dynamic programming comes to mind. Wouldn’t you then be able to use Array(repeating:count:) and repeat 0 (or something else) to achieve this then? Yes, less performant than alloc’ing array (since we need to fill in default values), but doing otherwise would go against Swift’s safety model.

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

> On 17 Apr 2017, at 21:18, Anders Kierulf wrote: > > >> On Apr 17, 2017, at 12:37 PM, Karl Wagner > > wrote: >> >>> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution >>>

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution > wrote: > > > on Fri Apr 14 2017, Karl Wagner wrote: > >> Personally, the only valid use-case I can think of is when you want to >> initialise an Array’s elements

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

> On Apr 17, 2017, at 10:52 AM, Anders Kierulf via swift-evolution > wrote: > > Swift needs a datatype that contains a fixed number of a given type; > basically a simple fixed-size array. > > Motivation: I’ve been porting code for Monte Carlo Tree Search in my >

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

> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution > wrote: > > Proposal: UnsafeMutablePointer almost provides what I need. However, it can > only allocate memory on the heap, or it can take a given blob of memory and > interpret it as something else.

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

Sorting a collection will not use `<` as the default predicate. In the Gist, I've outlined a design for `[Double].sorted()` which would exhibit identical behavior to what is proposed in this thread, but the design would be different under the hood. In brief, the "go-to" overload for sorting a

Re: [swift-evolution] [Pitch] Adding safety to arrays

on Mon Apr 17 2017, Karl Wagner wrote: >> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Apr 14 2017, Karl Wagner wrote: >> > >>> Personally, the only valid use-case I

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

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull wrote: > >> >> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> The point is that, when you manipulate two

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

> On 17 Apr 2017, at 21:11, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > 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 >

Re: [swift-evolution] And another access control idea

> On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution > wrote: > > Hi All, > > I’ve been following the access control discussion a little and I had an idea > that I wanted to throw out here. I know it’s too late and the idea doesn’t > provide source

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

> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>>

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

[swift-evolution] [Accepted] SE-0164: Remove final support in protocol extensions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md The review of SE-0164 "Remove final support in protocol extensions” ran from April 5...8, 2017. Feedback was light but positive, and the proposal is accepted.

Re: [swift-evolution] SE-0171: Reduce with inout

> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Apr 14 2017, Matthew Johnson > wrote: > >>> On Apr 14, 2017, at 9:05 PM, David Sweeris

[swift-evolution] [Accepted] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift” ran April 5...9, 2017. The first

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Comments in-line below -- Howard. On 17 Apr 2017, at 9:01 am, Xiaodi Wu wrote: This continues to forbid use cases that are critical. I think "critical" is overstating the importance. Plenty of successful languages do not have extensions. Extensions have been discussed

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

I've used code like the following example in similar situations and I've always (after a lot of profiling, trial and error) managed to get the (ugly) Swift code as fast as the C/C++ code. struct UnsafeStatic19x19 { var storage: ( E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,

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

> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution > wrote: > > This is the best approach that I’m aware of. It does bake in an ABI > assumption that the tuple layout will be contiguous and strided/addressable. > Monitor

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

I posted my branch and fixed up the Double case to account for your concerns (with a few inspired unit tests to validate) https://github.com/phausler/swift/tree/safe_nsnumber There is a builtin assumption here though: it does presume that

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

Extremely happy to see this outcome. Thank you Core Team for dealing with the seemingly never-ending arguments about access control, hopefully the majority of that is behind us now :^) > On Apr 17, 2017, at 5:25 PM, Douglas Gregor via swift-evolution > wrote: > >

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

> I think its important to point out that its more than aesthetics: because the > simple file and extensions scenario are so common, it forces us to use both > private and fileprivate fairly regularly, which increases the total number of > access control to work with on a daily basis. And I

Re: [swift-evolution] SE-0171: Reduce with inout

> On Apr 17, 2017, at 4:59 PM, Jaden Geller wrote: > >> >> On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> >>> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via

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

> On 18 Apr 2017, at 00:29, Karl Wagner wrote: > > >> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution >> > wrote: >> >> This is the best approach that I’m aware of. It does bake in an ABI >>

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

> That’s why open is a success IMHO I always appreciate when personal opinion is marked — I just want to point out this could apply to two aspects here ("that's why" and "open is a success" ;-) > I don’t think its worth arguing about renaming again. Yes, its technically a > better option,

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

> 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?___ swift-evolution mailing list swift-evolution@swift.org

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

- What is your evaluation of the proposal? + 1 - Is the problem being addressed significant enough to warrant a change to Swift? Yes - Does this proposal fit well with the feel and direction of Swift? I'm not completely sure. - If you have used other languages or libraries

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

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

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

Huge +1. We definitely need fixed-size arrays. Just in addition to elegantly importing C arrays, this will enable static matrix/tensor shapes for shape-safe compute operations like GEMM. Moreover I think we can learn from Rust about their recent discussion on constant generics. -Richard > On

Re: [swift-evolution] SE-0171: Reduce with inout

> On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Fri Apr 14 2017, Matthew

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

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

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

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md Hello

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

It seems Float.init(exactly: NSNumber) has not been updated to behave similarly? I would have to say, I would naively expect "exactly" to behave exactly as it says, exactly. I don't think it should be a synonym for Float(Double(exactly:)). On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via