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

Maybe the burden of proof required for this change is not met even though it frustrates those who dislike fileprivate. I honestly think our energies are better spent on other parts of the language than arguing on this... unless the discussion has time to grow into a proper holistic manifesto on

[swift-evolution] Treating an Enum's Cases as Its Subtypes

I'd like to discuss the possibility of treating the cases of a given enum as if they are subtypes of that enum. This seems like a natural thing to do because enum cases (especially when they have associated values) effectively define a closed set of subtypes. Doing so would allow for

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution > wrote: > > • init from/merge in a Sequence of Key/Value pairs (already raised as > SE-100: >

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

On 20 Feb 2017, at 06:05, Brent Royal-Gordon via swift-evolution wrote: >> On Feb 19, 2017, at 7:06 PM, Matthew Johnson wrote: >> >> Often you hand it to something owned by self, but it's also the case that >> you often hand it to something

Re: [swift-evolution] A concern

> On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution > wrote: > > One of the big plusses of Objective-C was that the entire manual was just a > few pages long. I have not looked it up, but IIRC the entire manual > describing the language was probably less than 50

Re: [swift-evolution] A concern

I listened to this podcast, and it is fantastic - I’m going to listen to it again. I used to have the same reservations about the directions that Swift was going in, but one thing Chris said in the podcast really changed my mind: the idea of progressively revealing complexity to the user. At

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

> On Feb 19, 2017, at 7:29 PM, David Waite wrote: > > Swift 2’s access modifiers had a very simple ‘elevator pitch’ - > “If you are writing code, by default everything within the module (app or > library) your are working in can see it, but other modules cannot.

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

> On Feb 19, 2017, at 7:06 PM, Matthew Johnson wrote: > > Often you hand it to something owned by self, but it's also the case that you > often hand it to something not owned by self, but that should not extend the > lifetime of self. I don't agree that it shouldn't

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

The message about D was from me. I'm actually quite familiar with D so I'll try to summarize it's take on purity here. # Pure in D D has the keyword `pure`, and the compiler enforces purity constraints. There is basically two types of pure functions: strongly pure ones and weakly pure one,

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

On Sun, Feb 19, 2017, at 10:57 PM, Xiaodi Wu via swift-evolution wrote: > Left unsaid from my reply about enums is that implicit conversions > should absolutely be added. We already have this magic for one > particular enum, Optional. I can only see a generalization of this being used for evil.

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

Sent from my iPad > On Feb 19, 2017, at 9:57 PM, Xiaodi Wu via swift-evolution > wrote: > > Left unsaid from my reply about enums is that implicit conversions should > absolutely be added. We already have this magic for one particular enum, > Optional. +1. I

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

Left unsaid from my reply about enums is that implicit conversions should absolutely be added. We already have this magic for one particular enum, Optional. I'm not arguing with you that enums are currently unsuitable. In fact I entirely agree. But Chris Lattner and others have said (now I'm

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

> On Feb 19, 2017, at 1:14 AM, Adrian Zubarev > wrote: > Here is a list of hidden and semi-hidden protocols from the standard library > that could be closed. Formatted version: > https://gist.github.com/DevAndArtist/168c800d784829be536c407311953ab7 >

Re: [swift-evolution] A concern

> On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution > wrote: > > Hello All, > > Its Sunday, time for some reflection... > > One of the big plusses of Objective-C was that the entire manual was just a > few pages long. I have not looked it up, but IIRC the

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

> On Feb 19, 2017, at 4:18 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sun, Feb 19, 2017 at 5:10 PM, Adrian Zubarev > > > wrote: > Because someInstance["key", .string("key1"),

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

Swift 2’s access modifiers had a very simple ‘elevator pitch’ - “If you are writing code, by default everything within the module (app or library) your are working in can see it, but other modules cannot. If you want other modules to see features of your module, you make them public. If

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

On Sun, Feb 19, 2017, at 06:40 PM, Xiaodi Wu via swift-evolution wrote: > On Sun, Feb 19, 2017 at 5:15 PM, Brent Royal-Gordon via swift- > evolution wrote: >> What is the harm of permitting an outside conformance to >> `SQLiteValue`? I'll put words in Brent's mouth

Re: [swift-evolution] Dictionary Enhancements

> On Feb 19, 2017, at 6:13 PM, Ben Cohen via swift-evolution > wrote: > >> On Feb 19, 2017, at 11:22 AM, Ole Begemann > > wrote: >> >>> On 17 Feb 2017, at 01:26, Ben Cohen via swift-evolution >>>

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

Sent from my iPad On Feb 19, 2017, at 6:30 PM, Brent Royal-Gordon wrote: >> On Feb 19, 2017, at 6:45 AM, Matthew Johnson wrote: >> >> 1. Swift *already* acknowledges that it is far easier to create a reference >> cycle through captured strong

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

I don't know very much about this topic, so I won't pretend that I have strong feelings about Michel's questions, but they are undeniably important and undoubtedly only one of many. Before we get to any syntactic bikeshedding, can the proponents of this feature write up a comparative summary to

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

Sent from my iPad > On Feb 19, 2017, at 6:52 PM, Daniel Duan wrote: > > >>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >>>

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

> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >> > wrote: >> >> I'm on vacation and don't have time

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

> On Feb 19, 2017, at 6:45 AM, Matthew Johnson wrote: > > 1. Swift *already* acknowledges that it is far easier to create a reference > cycle through captured strong references to `self` than any other way. This > is why you have to explicitly say `self.` in escaping

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

The reason you should not conform to _ExpressibleByBuiltinIntegerLiteral is that your type does not conform to the semantics of that protocol. Every protocol guarantees both syntax and semantics. (Well, almost every protocol; Error has no syntactic requirements at all, only semantic ones.)

Re: [swift-evolution] Dictionary Enhancements

> On Feb 19, 2017, at 11:22 AM, Ole Begemann wrote: > > >> On 17 Feb 2017, at 01:26, Ben Cohen via swift-evolution >> > wrote: >> >> Here is a list of commonly requested changes/enhancements to Dictionary, all >> of

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

Sent from my iPad > On Feb 19, 2017, at 5:52 PM, Tony Arnold via swift-evolution > wrote: > > >> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >> wrote: >> >> We need more examples to make this case. > > How do we

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

struct A : _ExpressibleByBuiltinIntegerLiteral { init() {} init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {} } struct B : ExpressibleByIntegerLiteral { init(integerLiteral value: A) {} } B(integerLiteral: A()) Here is another example. Am I supposed to do that? Definitely

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

On Sun, Feb 19, 2017 at 5:55 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > I don’t see it, can you elaborate a whole proposal first, otherwise I’m > not convinced. Why? > I'm sorry. I'm not sure what you mean. Can you clarify what you'd like to be more convinced of? > Am 20.

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

I don’t see it, can you elaborate a whole proposal first, otherwise I’m not convinced. Why? --  Adrian Zubarev Sent with Airmail Am 20. Februar 2017 um 00:51:18, Xiaodi Wu (xiaodi...@gmail.com) schrieb: On Sun, Feb 19, 2017 at 5:26 PM, Adrian Zubarev wrote:

Re: [swift-evolution] [Pitch] Allow use associated type outside of its protocol

Thanks! Waiting for the new version. > 在 2017年2月20日，上午7:42，Xiaodi Wu 写道： > > That is a new feature in Swift 3.1. > > > On Sun, Feb 19, 2017 at 5:32 PM, 曹剑楠 > wrote: > Sorry about my typo: > > public struct Album { > public

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

> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution > wrote: > > We need more examples to make this case. How do we provide those examples? This thread has been actively discussed for close to a week now, so it would be good to do something concrete

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

On Sun, Feb 19, 2017 at 5:26 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > Indeed, I have run into the same issue with this and have a proposal idea > saved up regarding anonymous enum cases and subtyping relationships. It > would not have been in-scope for phase 1, so I did not

Re: [swift-evolution] [Pitch] Allow use associated type outside of its protocol

That is a new feature in Swift 3.1. On Sun, Feb 19, 2017 at 5:32 PM, 曹剑楠 wrote: > Sorry about my typo: > > public struct Album { >> public let sectionedMediaItemInfos: [Sectioned]?} >> >> >> public struct Sectioned : SectionProtocol { >> public let title: String? >>

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

On Sun, Feb 19, 2017 at 5:15 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 18, 2017, at 10:58 PM, David Waite via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I am unsure if this feature is a good idea. Does someone have a > real-world

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

It’s funny. My favourites SQLite library actually does it as I suggested :) https://github.com/groue/GRDB.swift/blob/master/GRDB/Core/DatabaseValue.swift > On 20 Feb 2017, at 00:34, David Hart wrote: > >> >> On 20 Feb 2017, at 00:15, Brent Royal-Gordon via swift-evolution

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

> On 20 Feb 2017, at 00:15, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 18, 2017, at 10:58 PM, David Waite via swift-evolution >> wrote: >> >> I am unsure if this feature is a good idea. Does someone have a real-world >>

Re: [swift-evolution] [Pitch] Allow use associated type outside of its protocol

Sorry about my typo: public struct Album { public let sectionedMediaItemInfos: [Sectioned]?} public struct Sectioned : SectionProtocol { public let title: String? public let items: [Item] public init() { items = [] title = nil } } public extension Array

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

Because it’s not up to the client to decide how the design of the API supposed to work. --  Adrian Zubarev Sent with Airmail Am 20. Februar 2017 um 00:28:38, David Hart (da...@hartbit.com) schrieb: On 20 Feb 2017, at 00:19, Adrian Zubarev wrote: I’m polite

Re: [swift-evolution] [Pitch] Allow use associated type outside of its protocol

OK, my fault. That solved the problem. > var items: [Element.SectionItemType] I should use this. How about to allow using generic type Section directly instead of declare a protocol ```Swift public extension Array where Element == Section { var itemsCount: Int { return

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

> On 20 Feb 2017, at 00:19, Adrian Zubarev > wrote: > > I’m polite but I don’t see why every single piece is questioned with “why”. > > Your example is exactly the workaround I presented in first place. > Interesting right? But it still fails the challenge,

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

Indeed, I have run into the same issue with this and have a proposal idea saved up regarding anonymous enum cases and subtyping relationships. It would not have been in-scope for phase 1, so I did not write to the list about it. I’m short on time these days, but eventually I’ll propose it

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

Indeed, I have run into the same issue with this and have a proposal idea saved up regarding anonymous enum cases and subtyping relationships. It would not have been in-scope for phase 1, so I did not write to the list about it. I’m short on time these days, but eventually I’ll propose it

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

I’m polite but I don’t see why every single piece is questioned with “why”. Your example is exactly the workaround I presented in first place. Interesting right? But it still fails the challenge, because the set of types can be extended by the client, however at least with this there won’t be

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

On Sun, Feb 19, 2017 at 5:10 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > Because someInstance["key", .string("key1"), .integer(1), > .string(stringKeyInstance), .integer(intIndexInstance), > .integer(intIndexInstance), …] is simply ugly and should be hidden. Such > API looks

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

> On Feb 18, 2017, at 10:58 PM, David Waite via swift-evolution > wrote: > > 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? Strong coupling is

Re: [swift-evolution] [Pitch] Allow use associated type outside of its protocol

On Sun, Feb 19, 2017 at 5:04 PM, 曹剑楠 via swift-evolution < swift-evolution@swift.org> wrote: > Hi All, > > I’m coding for section like data structure. > For example: > > I have an Album struct, which has many MediaItems. > It has a sectioned property called "sectionedMediaItemInfos", which is an

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

> On 20 Feb 2017, at 00:10, Adrian Zubarev via swift-evolution > wrote: > > Because someInstance["key", .string("key1"), .integer(1), > .string(stringKeyInstance), .integer(intIndexInstance), > .integer(intIndexInstance), …] is simply ugly and should be hidden.

Re: [swift-evolution] Dictionary Enhancements

> On Feb 17, 2017, at 11:20 PM, David Waite > wrote: > > >> On Feb 16, 2017, at 5:26 PM, Ben Cohen via swift-evolution >> > wrote: >> >> Hi swift-evolution, >> >> Following up on Ted’s post regarding

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

Because someInstance["key", .string("key1"), .integer(1), .string(stringKeyInstance), .integer(intIndexInstance), .integer(intIndexInstance), …] is simply ugly and should be hidden. Such API looks horrible. Is this discussion really going to end with every statement being questioned with

[swift-evolution] [Pitch] Allow use associated type outside of its protocol

Hi All, I’m coding for section like data structure. For example: I have an Album struct, which has many MediaItems. It has a sectioned property called "sectionedMediaItemInfos", which is an array of sections. Each section represents for a disc, and has an "items" array contains all MedaItems

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

On Sun, Feb 19, 2017 at 4:51 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > Matthew has pretty much summed up everything with a single question in his > last reply. It makes me tired of repeating myself over and over again. > > Here’s the challenge for you: > > Implement a

[swift-evolution] [Draft] Guarded closures and `@guarded` arguments

I want to thank everyone who commented on the first draft of this proposal. I continue to believe the basic idea is a good one but there were a number of problems with the details of the design presented in that draft. They key insight that led to this new design is the idea of using a sigil

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

On Sun, Feb 19, 2017 at 4:46 PM, Karl Wagner wrote: > > > On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Sorry, I have read through this thread twice and do not understand the > point you are making. Can you explain your

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

Matthew has pretty much summed up everything with a single question in his last reply. It makes me tired of repeating myself over and over again. Here’s the challenge for you: Implement a subscript where the first parameter is a String (trivial), but the second to n are String’s and/or Int’s.

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

> On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution > wrote: > > Sorry, I have read through this thread twice and do not understand the point > you are making. Can you explain your example once more? > > Specifically, I do not understand why it is that your

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

> On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution > wrote: > > Sorry, I have read through this thread twice and do not understand the point > you are making. Can you explain your example once more? > > Specifically, I do not understand why it is that your

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

Sorry, I have read through this thread twice and do not understand the point you are making. Can you explain your example once more? Specifically, I do not understand why it is that your code should have problems with third-party types that conform to your protocol. If your protocol has

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

> The review of "SE-0155: Normalize Enum Case Representation" begins now and > runs through next Friday, February 26th. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md > > • What is your evaluation of the

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

Sent from my iPhone > On Feb 19, 2017, at 13:41, Lane Schwartz via swift-users > wrote: > > Hi all, > > I'm sure there are good reasons for this switch. Personally, I strongly > prefer email lists to forums. > > This move will make it harder for me to participate

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

https://github.com/DevAndArtist/swift-evolution/blob/metatypes/proposals/0126-refactor-metatypes.md --  Adrian Zubarev Sent with Airmail Am 19. Februar 2017 um 22:59:18, David Hart (da...@hartbit.com) schrieb: Where can I find a link to an updated version? On 19 Feb 2017, at 21:42, Adrian

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

Where can I find a link to an updated version? > On 19 Feb 2017, at 21:42, Adrian Zubarev via swift-evolution > wrote: > > We added a note to the proposal: > > Both Type and AnyType will be declared in the Swift standard library > even if part of the implementation

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

> On Feb 19, 2017, at 12:49 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >> > wrote: >> >> I'm on vacation and don't have time

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

On Sat, Feb 18, 2017 at 8:49 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > 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

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 Nevertheless it’s a bit unclear to me what is the impact of these additional collections on the ownership of the dictionary. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > If you have used other

Re: [swift-evolution] A concern

The first time I read through the swift manual. I thought to myself, "swift is Apples version of C++" The book on c -- the C programming language by Brian kernighan -- is around 200 pages. As for objective c I've yet to see a book that covers more than a single chapter Before diving into cocoa

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

I'm going to update the draft with points addressed here and the twitter conversation. There have been quite a few implications to consider pointed out. This feature is not 'for' the compiler as much as it is for humans writing code, but I will address that in the update. On Sun, Feb 19, 2017 at

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

We added a note to the proposal: Both Type and AnyType will be declared in the Swift standard library even if part of the implementation might be compiler magic. That move is really important to allow developers to created custom nested types named as Type. ModuleName.TypeName.Type is

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

> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution > wrote: > > 7. Is it desirable that the optimizer sometime take the pure attribute to > heart to combine multiple apparently redundant calls into a single one? Or is > pure not intended to be usable

Re: [swift-evolution] A concern

Very interesting topic! I disagree with the premise. Without having written a single line of Objective-C (nor Cocoa), I was able to get started with Swift in maybe 2 busy nights. Advanced concepts are difficult to master, but imho the learning curve is not that steep. There are experts in

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

> On Feb 19, 2017, at 2:16 PM, Anton Zhilin wrote: > > 2017-02-19 22:59 GMT+03:00 Matthew Johnson >: > > > >> On Feb 19, 2017, at 1:32 PM, Anton Zhilin >

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

> On Feb 19, 2017, at 1:47 PM, Michel Fortin via swift-evolution > wrote: > > I'm a bit disappointed to see this discussion bikeshedding the syntax without > clarifying much the semantics. Here's a few question of semantic nature. +1. I think the syntactic

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

2017-02-19 22:59 GMT+03:00 Matthew Johnson : On Feb 19, 2017, at 1:32 PM, Anton Zhilin wrote: > > Now that I think about it, generic throws does not exactly cover rethrows. > Firstly, rethrows has semantic information that function itself does not

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

It’s expected that if you need resilience, then you will throw an “open” enum. Essentially, we pass resilience of typed throws on to those who will hopefully establish resilience of enums. If you prefer separate error types, then declare a base protocol for all your error types and throw a

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

> On Feb 19, 2017, at 1:32 PM, Anton Zhilin wrote: > > Now that I think about it, generic throws does not exactly cover rethrows. > Firstly, rethrows has semantic information that function itself does not > throw—it would be lost. > Can you elaborate further on what

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

> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution > > wrote: > > 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

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

I'm a bit disappointed to see this discussion bikeshedding the syntax without clarifying much the semantics. Here's a few question of semantic nature. The base principle of a pure function is that it has no side effects. But it's quite clear that at least some side effects will need to be

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

2017-02-19 0:16 GMT+03:00 Martin Waitz : > > Now some bike-shedding: > I’m not really happy with the `throws(Type)` syntax, as it is too close to > function parameters. > Why exactly is `throws Type` ambiguous? > The proposal mentions `Type -> Result` as potential thrown type,

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

Now that I think about it, generic throws does not exactly cover rethrows. Firstly, rethrows has semantic information that function itself does not throw—it would be lost. Secondly, rethrows allows a function with multiple throwing function parameters to become non-throwing iff all the arguments

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

> On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 19 Feb 2017, at 10:20, Goffredo

Re: [swift-evolution] Dictionary Enhancements

> On 17 Feb 2017, at 01:26, Ben Cohen via swift-evolution > wrote: > > Here is a list of commonly requested changes/enhancements to Dictionary, all > of which would probably be appropriate to put together into a single > evolution proposal: > > init from/merge in

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

> On 19 Feb 2017, at 19:14, Chris Lattner via swift-evolution > wrote: > > >> On Feb 18, 2017, at 9:59 PM, Kevin Nattinger wrote: >> >> >>> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution >>> wrote:

Re: [swift-evolution] A concern

No, I was referring to the original Apple document that introduced Objective-C. But actually C is a good example. The original work by Ritchie and Kernighan was also quite limited in scope. A small book and could easily be learned in a WE, I think I still have it somewhere in my library...

Re: [swift-evolution] A concern

Interesting, You are right somewhere, today following the swift evolution, mastering swift with the use of the new standard lib and Cocoa is time consuming, and request to dedicate serious resources. I am not sure that the complexity come from the core language itself, it become complexe

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

This proposal directly addresses one of my least favorite patterns in Swift. It's a good improvement and I would be content with it being accepted as-is. However I do still feel that the solution is "clunky," and that being able to mutate a dictionary entry via the Optional would be much

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

> On Feb 18, 2017, at 9:59 PM, Kevin Nattinger wrote: > > >> 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

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

Hi Dave, > On Feb 18, 2017, at 8:49 PM, Dave Abrahams via swift-evolution > wrote: > > 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

Re: [swift-evolution] A concern

> On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution > wrote: > > Hello All, > > Its Sunday, time for some reflection... > > One of the big plusses of Objective-C was that the entire manual was just a > few pages long. I have not looked it up, but IIRC the

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

That’s the whole point I was making. :) Thank you Matthew. That makes my example a real world example and not just some bike shedding. --  Adrian Zubarev Sent with Airmail Am 19. Februar 2017 um 18:50:31, Matthew Johnson (matt...@anandabits.com) schrieb: Sent from my iPad On Feb 19, 2017,

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

Sent from my iPad > On Feb 19, 2017, at 10:39 AM, Adrian Zubarev > wrote: > > Still not what I was asking about. > > Module A contains a single open protocol: open protocol P { func foo() } > Module B contains a single open class that conforms to P: > open

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

Sent from my iPad > On Feb 19, 2017, at 11:29 AM, David Waite via swift-evolution > wrote: > > Just FYI, I solved this issue in my own library (which included a json > jpointer implementation) via: > > public enum SubscriptParameter { > case string(String) >

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

Sent from my iPad > On Feb 19, 2017, at 11:34 AM, Brandon Knope via swift-evolution > wrote: > > I really like this. Seems much more elegant and simple this way +1 > >> On Feb 17, 2017, at 4:45 PM, Joe Groff via swift-evolution >>

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

> On 19 Feb 2017, at 17:36, David Hart wrote: > > This makes more sense already. But in this case, wouldn't I be interested, as > a client, in creating my own TextStreams, some of which might write to a > custom log file, to a web service, etc... ? > > On 19 Feb 2017, at

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

Try to pass let intInstance = 42 in your function. ;) That will result in .int(intInstance). My implementation does not need that at all. --  Adrian Zubarev Sent with Airmail Am 19. Februar 2017 um 18:29:54, David Waite (da...@alkaline-solutions.com) schrieb: Just FYI, I solved this issue

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

I really like this. Seems much more elegant and simple this way > On Feb 17, 2017, at 4:45 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution >> wrote: >> >> I suggest we

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

Just FYI, I solved this issue in my own library (which included a json jpointer implementation) via: public enum SubscriptParameter { case string(String) case int(Int) } extension SubscriptParameter : ExpressibleByIntegerLiteral { public init(integerLiteral value: Int) { self =

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

I think this is the not an easy topic to get right, there is not enough evidence in practice to remove it in terms of it being actively harmful and having a better solution at hand. What you see as being not awesome for protocols and extensions others may see taking it away as a sacrifice that

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

> On 19 Feb 2017, at 18:10, Goffredo Marocchi wrote: > > Good thing that both can exist then :). One day we may even get things such > as abstract classes and be allowed to model abstentions wth classes and > reference types better without it being seen as an attack to

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

Good thing that both can exist then :). One day we may even get things such as abstract classes and be allowed to model abstentions wth classes and reference types better without it being seen as an attack to value types ;).. Sent from my iPhone > On 19 Feb 2017, at 13:55, David Hart

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

The are no reasons to allow that to the client. A key is a String and an index is an Int. I don’t see any point why the client would need its own model of generating a String or an Int. The usage of that protocol is a limitation of the language because we don’t support Either types, so I fall

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

> On 19 Feb 2017, at 17:00, Adrian Zubarev > wrote: > > In my case we don’t have an Either type, nor do we allow implicit type > conversions. Remove the property from my protocol and forget about the enum > that I used there. Conform to the protocol in your

  1   2   >