Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

I was a little afraid of that when I read Teds message first, but I thought I give it a try. This additional change doest feel heavy at all to me. My question is, when is the right time for this if not now? If not now than this won’t happen in Swift 4.1 either, and I highly doubt it for Swift

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

What wrong with [unowned self] On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote: > This reminded me of an idea I had long time ago which will have a similar > effect: add a way to disable implicit captures for closures. FWIW. > > > On Feb 18,

Re: [swift-evolution] [Draft] open and public protocols

I am unsure if this feature is a good idea. Does someone have a real-world use for this which isn’t just hiding strong implementation coupling behind a protocol? When I consume a protocol, it is under the assumption that the protocol is documented such that I would be able to work against

Re: [swift-evolution] final + lazy + fileprivate modifiers

How exactly is the use of scope private harmful? Do you have specific examples when scope private was harmful? > On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution > wrote: > > On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

> On Feb 18, 2017, at 12:40 AM, Xiaodi Wu wrote: > > On Sat, Feb 18, 2017 at 1:07 AM, David Waite > wrote: > > I believe this proposal is different in that it only requires specification > for clarity

Re: [swift-evolution] [Draft] open and public protocols

There's no way to make a source-breaking change non-breaking. A migration path that meanders through several different designs just increases the aggregate pain over multiple releases. The proposed migration path has the great drawback that, even once approved, no person would actually be allowed

Re: [swift-evolution] [Pitch] @testable private members

> On Feb 18, 2017, at 10:14 AM, Matthew Johnson via swift-evolution > wrote: > > When writing unit tests sometimes it is necessary to artificially elevate a > member to `internal` in order to make it visible to unit tests where it could > otherwise be `private` or

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

Ted Kremenek just wrote a post detailing Swift 4 stage 2. Here is the relevant part again [unable to increase the quotation level for unclear reasons, but the following is a verbatim copy from that message]: Timeline Stage 2 starts right now. All design work and discussion for stage 2 extends to

Re: [swift-evolution] [Pitch] @testable private members

@testable is already a hack. Why not just extend it to fileprivate members? ~Robert Widmann > On Feb 18, 2017, at 1:14 PM, Matthew Johnson via swift-evolution > wrote: > > When writing unit tests sometimes it is necessary to artificially elevate a > member to

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> I’d like to revive an additive proposal

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote: > I don’t think there is evidence that scope private in Swift3 is > "actively harmful”. This thread would quite simply not exist if not to present exactly that evidence. It exists; we, the change's detractors,

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

On Fri, Feb 17, 2017, at 08:45 PM, Joe Groff via swift-evolution wrote: > • What is your evaluation of the proposal? Extremely strong +1. Unlike others, I agree with the proposed deprecation of BitwiseOperations. It's not pulling its own weight under this new model. I encourage other

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

I'm on vacation and don't have time for a full review right now, but I am concerned that wild this proposal would make enums more general and uniform with the rest of the language , they also would become much more awkward for common use cases. I have recently been very pleased that I didn't

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

This reminded me of an idea I had long time ago which will have a similar effect: add a way to disable implicit captures for closures. FWIW. > On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution > wrote: > > # `@selfsafe`: a new way to avoid reference

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution > wrote: > > I’d like to revive an additive proposal that couldn’t make it into Swift 3. > This proposal has a small improvement to the language compared to other big > features currently being

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On 17 Feb 2017, at 23:30, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 17, 2017, at 4:17 PM, Daniel Leping wrote: >> >> I don't think I can (fully) agree with you, because a closure purity is not >> something you

[swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

# `@selfsafe`: a new way to avoid reference cycles * Proposal: [SE-](-selfsafe.md) * Authors: [Matthew Johnson](https://github.com/anandabits) * Review Manager: TBD * Status: **Awaiting review** ## Introduction This proposal introduces the `@selfsafe` function argument attribute which

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 14:28, Matthew Johnson wrote: > > >> On Feb 18, 2017, at 3:52 PM, David Sweeris wrote: >> >> >>> On Feb 18, 2017, at 13:12, Matthew Johnson wrote: >>> >>> On Feb 18, 2017, at 3:01 PM, David

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 3:52 PM, David Sweeris wrote: > > >> On Feb 18, 2017, at 13:12, Matthew Johnson wrote: >> >> >>> On Feb 18, 2017, at 3:01 PM, David Sweeris wrote: >>> >>> On Feb 18, 2017, at 12:41 PM, Matthew

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 3:43 PM, Charles Srstka wrote: > >> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> There are good reasons a library may not wish to allow users to

Re: [swift-evolution] [Draft] open and public protocols

Great proposal Matthew, huge thanks for pushing this forward and putting it together. I simply cannot wait for this to be implemented. :) +1 I spotted two typos while reading: public protocol P P{} - one P too much There is somewhere an erro without an r at the end --  Adrian Zubarev Sent

Re: [swift-evolution] [Manifesto] Ownership

Le 17 févr. 2017 à 15:08, John McCall via swift-evolution a écrit : > > We don't have an initial implementation yet, sorry. I'm sure it'll vary a > lot by the application. My hope is that it'll just be a few extra non-atomic > loads and stores around every access,

Re: [swift-evolution] [Draft] open and public protocols

Protocols solve way more problems than this. Sometimes they are used as backdoors to existing APIs as well. It’s simply an implementation artifact that such a protocol might end up public, but there is no point to allow the client to conform to it. I also showed a concrete example in the

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 13:12, Matthew Johnson wrote: > > >> On Feb 18, 2017, at 3:01 PM, David Sweeris wrote: >> >> >>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> ## Source

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution > wrote: > > There are good reasons a library may not wish to allow users to add > conformances to a protocol. For example, it may not wish to expose the > conforming concrete types. While similar

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On Feb 18, 2017, at 3:16 PM, Haravikk wrote: > > >> On 18 Feb 2017, at 16:28, Matthew Johnson > > wrote: >> >>> >>> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] [Manifesto] Ownership

Le 17 févr. 2017 à 3:25, John McCall via swift-evolution a écrit : > func endScope(_ value: T) -> () {} Just to be sure, that is the same thing as `move` where you to discard the return value, right? let something = make() endScope(something) vs.

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On 18 Feb 2017, at 16:28, Matthew Johnson wrote: > >> >> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution >>>

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

> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution > : > > Thank you for taking the time to put this proposal together Anton! I really > want to see typed throws make it into Swift 4. This will be a very nice > feature to have. > > I noticed

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 3:01 PM, David Sweeris wrote: > > >> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution >> wrote: >> >> ## Source compatibility >> >> This proposal breaks source compatibility, but in a way that allows for

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

> On Feb 18, 2017, at 2:55 PM, Daniel Duan wrote: > >> >> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> >>> • What is your evaluation of the proposal? >> >> +1. I am

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution > wrote: > > ## Source compatibility > > This proposal breaks source compatibility, but in a way that allows for a > simple mechanical migration. A multi-release stratgegy will be used to roll >

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

> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution > wrote: > > >> • What is your evaluation of the proposal? > > +1. I am extremely confident that this is the right direction to go in. > > I really like Brent’s idea for allowing us to

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

Hi Brent, > On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 17, 2017, at 7:26 PM, John McCall wrote: >> >> Proposal link: >>

[swift-evolution] [Draft] open and public protocols

Now that we’re in phase 2 I’d like to officially propose we introduce `open` protocols and require conformances to `public` protocols be inside the declaring module. Let’s use this thread for feedback on the official proposal. After a healthy round of discussion I’ll open a PR to submit it

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

> The review of SE-0154 "Provide Custom Collections for Dictionary Keys and > Values" begins now and runs through February 22, 2017. The proposal is > available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md > >

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

Hi Slava, > On Feb 18, 2017, at 12:30 AM, Slava Pestov via swift-evolution > wrote: > > +1, two small questions: > > - If two cases have the same base name but different full names, will > matching on the base name match both cases, or will it be an error? An

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

> • What is your evaluation of the proposal? +1 I assume the “SignedNumber” protocol is the same as the existing one in the standard library. That is to say, Strideable.Stride will now conform to Number and have operators. Also minor nitpick, would it be too onerous to require

Re: [swift-evolution] [Pitch] @testable private members

Whoops, accidentally sent this off-list. -thislooksfun (tlf) > On Feb 18, 2017, at 12:26 PM, thislooksfun wrote: > > Big +1 from me. I see no point in having to elevate access just to make sure > everything is working. > > -thislooksfun (tlf) > >> On Feb 18, 2017,

[swift-evolution] [Pitch] @testable private members

When writing unit tests sometimes it is necessary to artificially elevate a member to `internal` in order to make it visible to unit tests where it could otherwise be `private` or `fileprivate`. We could introduce an `@testable` attribute that could be applied anywhere an access modifier is

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

> > - What are the memory layout optimizations described here? From a first > glance this looks purely syntactic. The compiler could “refactor” the payloads among all enum cases to maximise overlapping. If you know that an enum’s payload always contains a reference-counted or shared object,

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

The problem I was describing is about nested types named .Type, indeed. Assuming the proposal would go with Type, then it means you _might_ be able to create nested types called Type, but you always would need to call if through the whole namespace (e.g. A.B.Type). That is a huge downside.

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

> • What is your evaluation of the proposal? +1. I am extremely confident that this is the right direction to go in. I really like Brent’s idea for allowing us to distinguish the parameter label from what he calls the “internal name”. In the value subtyping manifesto I recently

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

> On 18 Feb 2017, at 16:27, Karl Wagner wrote: > > - I wonder if we could try something more ambitious. Since the list of thrown > errors is resilience-breaking for the function, it is only beneficial for > versioned and @inlineable functions. They should not be able

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

Thank you for taking the time to put this proposal together Anton! I really want to see typed throws make it into Swift 4. This will be a very nice feature to have. I noticed that you included Joe Groff’s idea of replacing `rethrows` by making every function have an error type which is by

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution >> wrote: >> >> This is an idea I had while working with collections, and is particularly >>

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

> > • What is your evaluation of the proposal? +1. Very nice! > • 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? Very much so. > • If you have used other

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

> 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? Yes > If you have used other languages or libraries with a similar feature, how do > you

Re: [swift-evolution] [Manifesto] Ownership

Hi John, This is fantastic! I’ve been eagerly anticipating this. It looks very much as I was hoping it would. I can’t wait to see this vision come to life! You only show a mutating generator example. Do you also plan to allow shared generators? One topic you don’t touch on that feels

Re: [swift-evolution] Implicit conversion between primitive types

The idea of "f for Float" has been raised here. Core team members have said that it's been explicitly avoided in Swift on purpose, because in their judgment it has low readability. Instead of "5.0f" you write "5 as Float". (Unless I'm mistaken, you can also change the default floating point type

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

Type is a bad name for a public type: FooType is almost always a better name. Libraries that describe “just types”, Swift types, can as well use Metatype or Mirror or something. For nested types, like Foo.Type, in the meaning of “type of Foo“, Type can’t be used even now. I’d give up on Type name

Re: [swift-evolution] Implicit conversion between primitive types

> On Feb 18, 2017, at 7:23 AM, Milos Jakovljevic via swift-evolution > wrote: > > Are there are any plans of adding implicit conversion between primitive types? > > For example > > var float = 5.0 > > func accept(float: Float) { >print("this is \(float)") > }

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

> On 17 Feb 2017, at 19:45, Anton Zhilin via swift-evolution > wrote: > > Now this is on-topic, I guess. > Last time we stopped at John McCall’s syntax: > > extension MyError: Error { ... } > > func foo() throws(MyError) -> MyResult > It’s conservative and prevents

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 10:56 PM, Xiaodi Wu wrote: > > On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe > wrote: > >> On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] final + lazy + fileprivate modifiers

I searched thought my code and most uses of fileprivate were for same-file extensions which would be solved by #2 as well. The other usages are mostly "related" types, which could possibly work with #2 if these were made inner types instead. Two examples: A "Slots" struct with a collection of

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

> On 18 Feb 2017, at 14:16, David Rönnqvist via swift-evolution > wrote: > > On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution > wrote: > >> +1, two small questions: >> >> - If two cases have the same base name but different

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

Personally I’d prefer Metatype and AnyMetatype to get rid of the restriction where you mostly cannot create custom types called Type, which annoys me a lot. Sometimes Kind as a good workaround but there are times where Kind doesn’t fit. :/ --  Adrian Zubarev Sent with Airmail Am 18. Februar

[swift-evolution] Implicit conversion between primitive types

Are there are any plans of adding implicit conversion between primitive types? For example var float = 5.0 func accept(float: Float) { print("this is \(float)") } This will raise a warning that double cannot be cast to float. Which is really frustrating since i always have to add type

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

> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution > wrote: > > +1, two small questions: > > - If two cases have the same base name but different full names, will > matching on the base name match both cases, or will it be an error? I feel that it would

[swift-evolution] [Proposal] Typed throws

I’ve created a proposal draft, copy-pasting some parts from David Owens’ proposal. Here it is . I had to make one addition, which hasn’t been discussed yet. Look at Multiple throwing calls

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

> Wouldn’t that mean that you couldn’t use your Swift library in Objective-C > anymore, at least the error type as an NSError? > That's the meaning of "break with Objective-C" here ;-) — but note that I wrote about allowing to do so, not forcing: Now, we can only declare that something is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md Reply text: However, occasionally a constructor might be non-copying on purpose, so we'll need a way to disable the warning. How about the determination

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

> On Feb 17, 2017, at 7:26 PM, John McCall wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md > > • What is your evaluation of the proposal? I'm torn. Being able to handle the

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On 18 Feb 2017, at 10:54, Brent Royal-Gordon wrote: > >> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution >> wrote: >> >> This is an idea I had while working with collections, and is particularly >> inspired by those that use

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 2:15 PM, Joanna Carter via swift-evolution > wrote: > > There are also times when I want to declare a base class that I am expecting > users to derive from, especially an abstract class. I want a means of > declaring that certain stuff can only

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution > wrote: > > This is an idea I had while working with collections, and is particularly > inspired by those that use common index types. > > Consider for example an array; for indices it simply uses an

Re: [swift-evolution] final + lazy + fileprivate modifiers

> While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary complications that > only serve to clutter the language. > > It would make a lot more sense to just have

[swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

This is an idea I had while working with collections, and is particularly inspired by those that use common index types. Consider for example an array; for indices it simply uses an integer, however, while this is a perfectly valid type to use it opens up the possibility of integers from any

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> On Feb 17, 2017, at 3:18 PM, Douglas Gregor wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md > > • What is your evaluation of the proposal? I think a warning is very

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

> On 18 Feb 2017, at 01:45, Joe Groff via swift-evolution > wrote: > > • What is your evaluation of the proposal? Solid +1, though like others I disagree with deprecating BitwiseOperations, and feel it should be integrated into the protocol hierarchy. >

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> What is your evaluation of the proposal? It’s clearly a concern and one that should be addressed. A lot of people have bought up the didSet {} property observers are not called when things are set here, either. This is true, but unlike property observers, these are attributes, and I don’t

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

Hello Swift community: Thank you for your reviews for my proposal. As you may have seen, this proposal contains two solutions originally: Compiler magic Compile-time checking However even though Solution: Compiler magic is viable, according to some of feedback from several reviewers, a

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

+1, two small questions: - If two cases have the same base name but different full names, will matching on the base name match both cases, or will it be an error? - What are the memory layout optimizations described here? From a first glance this looks purely syntactic. Slava > On Feb 17,

Re: [swift-evolution] final + lazy + fileprivate modifiers

My 2c: +1 to reverting private to the Swift 2 meaning and deprecating or using fileprivate as an alias for private. As a framework developer I am constantly deciding backward and forwards to go private only to realise that my embracing extensions makes it impossible to allow internal