Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Le 30 nov. 2016 à 16:00, João David via swift-evolution > a écrit : > > Definetely the access control topic is highly contestable in the Swift scene > but nevertheless I really strive for more flexibility in terms of how can I > decouple and decompose my code

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

> On Nov 30, 2016, at 4:05 PM, Ramiro Feria Purón > wrote: > > Formally, perhaps the proposal should include the following: > > 1. Missing type parameters are assumed to be implicit and trailing (as in the > particular case of all type parameters missing).

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

> On Nov 30, 2016, at 4:09 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Nov 28 2016, Douglas Gregor > wrote: > >>> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution >>

[swift-evolution] [Pitch] Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

Hi swift-evolution, Below is a draft proposal for a change to facilitate fixing some memory safety issues in the standard library. If you’re interested in the implementation, PRs can be found here: [stdlib] [WIP] Eliminate version of Array.append(contentsOf:) that takes a Collection

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

on Wed Nov 30 2016, Kevin Ballard wrote: > This sounds like a sensible idea. But there is one behavioral change you > haven't addressed, which is that this changes how indexes work on the > slice. With all other slice types that come to mind, the slice shares > the

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

on Mon Nov 28 2016, Douglas Gregor wrote: >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution > wrote: >> >> Problem: >> >> Currently, it is not possible to be explicit about the generic parameters >> (type parameters)

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

Formally, perhaps the proposal should include the following: 1. Missing type parameters are assumed to be implicit and trailing (as in the particular case of all type parameters missing). 2. _ is allowed as a placeholder when specifying explicit parameters in a function call. The corresponding

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Dramatically source-breaking, dubious benefit. -1. Charles > On Nov 30, 2016, at 4:40 PM, Erica Sadun via swift-evolution > wrote: > > This pitch is breaking, and should be considered under the phase 1 timeframe. > gist here:

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Nov 30, 2016, at 1:13 AM, Tyler Cloutier wrote: >> I think we should formally decide that a “nice” wrapper for libc is a >> non-goal. There is too much that doesn’t make sense to wrap at this level - >> the only Swift code that should be using this is the

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Breaking changes, at this point, have a high bar for acceptance. I am failing to see how the downsides presented here are enough to warrant a change. Also: > Developers who follow this rule may accidentally insert newValue or oldValue > in the wrong observer. It is not that uncommon One

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Perhaps an alternative would be to eliminate the newValue/oldValue magic names and require they be named in parens instead? l8r Sean > On Nov 30, 2016, at 4:40 PM, Erica Sadun via swift-evolution > wrote: > > This pitch is breaking, and should be considered under

[swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

This pitch is breaking, and should be considered under the phase 1 timeframe. gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b As usual, I will update the gist with feedback. Please refer to gist rather than this email for the latest revisions. -- E Removing

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

This sounds like a sensible idea. But there is one behavioral change you haven't addressed, which is that this changes how indexes work on the slice. With all other slice types that come to mind, the slice shares the same indexes as the base, e.g. let ary = Array(0..<10) print(ary[3]) //

[swift-evolution] Details of what source compatibility with Swift 3 means

Hi, One of the Stage 1 goals of Swift 4 is source compatibility with Swift 3, but what does that precisely mean and how will we determine if the goal is achieved? This is the current proposal of how this goal ties back to the Swift 3.x and Swift 4 releases. Is there anything else that’s

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

Adrian and Karl, OK, thanks for the constructive feedback. On Wed, Nov 30, 2016 at 11:45 AM, Karl wrote: > > > On 30 Nov 2016, at 14:11, Steve Prescott via swift-evolution < > swift-evolution@swift.org> wrote: > > > > As the original poster of this thread, I wanted to

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

+1. Sensible change. > On 30 Nov 2016, at 18:15, Nate Cook via swift-evolution > wrote: > > Hello all— > > This is a proposal for a fairly minor change in slicing behavior for unsafe > buffers. > > Nate > > > -- > > > This proposal changes Swift's typed

Re: [swift-evolution] [swift-build-dev] [Accepted] SE-0146: Package Manager Product Definitions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md The review of "SE-0146: Package Manager Product Definitions" ran from November 18...28. The proposal has been *accepted*. The proposal received no feedback, but as the

[swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

Hello all— This is a proposal for a fairly minor change in slicing behavior for unsafe buffers. Nate -- This proposal changes Swift's typed UnsafeBufferPointers to be their own slice type, like the UnsafeRawBufferPointer types. This is a minor change in the subscript API of

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 30 Nov 2016, at 14:11, Steve Prescott via swift-evolution > wrote: > > As the original poster of this thread, I wanted to re-state the original > question: > > Should enums REQUIRE parameter names? > > Pro: The syntax would more closely match that

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

While I agree with most of your points Dave, I think forgetting to call super is very much a (hard to debug) real world problem today. Especially new developers seems unsure or likely to forget to call super when it is required. I think my point is this; When you subclass code you have not

[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Definetely the access control topic is highly contestable in the Swift scene but nevertheless I really strive for more flexibility in terms of how can I decouple and decompose my code arch among several source files. As an example, I reckon that the current approach of attributing properties

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

Or perhaps in a more "swifty" way, use _ for implicit type parameters, i.e.: f<_,T>() On Thu, 1 Dec 2016 at 01:13 Ramiro Feria Purón wrote: > Douglas, > > Regarding the question on the restriction for type parameters to appear on > the signature, the answer is

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

Douglas, Regarding the question on the restriction for type parameters to appear on the signature, the answer is remain. The proposal does not intend this restriction to be lifted. One might expect to find a few legitimate cases where having it lifted would be handy or desirable. They seem to

Re: [swift-evolution] Proposal: Improve Import of Scanner APIs into Swift 3

/// Revised API for avoiding usage of AutoreleasingUnsafeMutablePointer and better Optional usage. /// - Experiment: This is a draft API

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

> “this method is private but overridable,” +1 ;-) It would make the language more orthogonal — but I'm afraid this option died when "open" was added, and I have to admit that it would make things complicated as well: Methods that shouldn't be called directly (like UIView.draw and

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

–1 We don’t have this behaviour with functions, so there is no need for that on enum cases. Something like this should be some point of the API Design Guideline instead. Sometimes there is just no need for an extra label on an enum case with assocaited values. --  Adrian Zubarev Sent with

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

As the original poster of this thread, I wanted to re-state the original question: Should enums REQUIRE parameter names? Pro:The syntax would more closely match that for functions, which requires names for all parameters (unless you say “_”) vs. the current syntax that is sort of

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

Fair point, the more and more I’m thinking about default values, the more I’m convinced here. And yes, as I mentioned before, default value would solve the problem in my API. I’m thinking of adapting the pitched idea so I almost get the right behaviour for free when Swift 4 drops. -- 

[swift-evolution] Proposal: Improve Import of Scanner APIs into Swift 3

Working on a function for Foundation’s Scanner I stumbled on this LLVM crash: https://bugs.swift.org/browse/SR-3295 This got me thinking about a workaround and I would like to prose this: When importing Foundation into Swift 3, all AutoreleasingUnsafeMutablePointer? should instead be

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution > wrote: > > On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon wrote: >>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

Sent from my iPhone > On 30 Nov 2016, at 06:40, David Hart via swift-evolution > wrote: > > For example, here is a design pattern I would find clearer with explicit type > information: > > let cat = factory.get() > > vs > > let cat: Cat = factory.get() > >