Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

Project: http://swiftfire.nl > On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution > wrote: > > Hi all, > > Here’s a draft proposal following > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html > . > > The idea is simp

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

I don’t know if you want to add this to the ‘criticism’ or not. 1) The information content added by “fileprivate” is questionable because of the ‘soft default’: - People will switch from private to fileprivate without much thought if that is desirable or not. - Other people will default to ‘fil

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

I believe the actual problem is with ‘internal’, and that our problems with private are a symptom of that deeper issue. We need to fix the deeper underlying issue. >From this blog post (https://developer.apple.com/swift/blog/?id=11), it seems >Internal was meant to share parts of types which s

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

~Robert Widmann 2017/02/21 2:16、Jonathan Hull のメッセージ: > It is how it interacts with our current access control. The scope based > nature of this will conflict with the file based nature of the stuff left > from Swift 2. I am convinced we need to overhaul it in one sweep to fit one > metaph

Re: [swift-evolution] [Manifesto] Ownership

> Le 20 févr. 2017 à 23:16, John McCall a écrit : > > >> On Feb 20, 2017, at 4:55 PM, Florent Bruneau >> wrote: >> >> >>> Le 20 févr. 2017 à 18:22, John McCall a écrit : >>> On Feb 20, 2017, at 3:40 AM, Florent Bruneau wrote: Hi John, I've spent 3 h

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

> On Feb 20, 2017, at 1:15 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >>> mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Pitch] Let's talk about submodules

Maybe we should try to collect what people want from submodules first. I wanted modules for organisational purposes, however with the arrival of SPM that need has been almost completely removed. At least to the point that I do not feel that they are absolutely necessary. Have the people who wan

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

7:44, Dimitri Racordon via swift-evolution >> wrote: >> >> Hi all, >> >> Here’s a draft proposal following >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html. >> The idea is simplify Swift’s syntax by getting rid of th

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

It is how it interacts with our current access control. The scope based nature of this will conflict with the file based nature of the stuff left from Swift 2. I am convinced we need to overhaul it in one sweep to fit one metaphor or the other. The more we mix them, the harder it is to wrap you

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sounds distressingly anti-modular! Really, these kinds of hypotheticals can be addressed when the need arises. For now it's a hypothetical fear about a hypothetical issue that isn't expressible and highly discouraged by this system - why produce an inverted dependency when you could simply reb

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

> On Feb 20, 2017, at 6:04 PM, Chris Lattner wrote: >> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> It’s expected t

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

> On Feb 19, 2017, at 12:04 PM, Anton Zhilin via swift-evolution > wrote: > > 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. > You’ve just re-inve

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

It’s probably best we explain this motivation under “Alternatives Considered”. I forked and updated the gist—feel free to “pull” in the changes… copy and paste the document https://gist.github.com/JadenGeller/c18b1be8e7b9fa3023e98b84fca423ca#multiple-declarations-instead-of-extensions

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

swift-evolution mailto:swift-evolution@swift.org>> wrote: Hi all, Here’s a draft proposal following https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html. The idea is simplify Swift’s syntax by getting rid of the `open` access modifier. A rendered version of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 10:51 PM, Robert Widmann wrote: > >> On a side note, I do think that people will quickly want a way to reference >> a particular submodule boundary with access modifiers. It may not be part >> of this proposal, but it is somewhat inevitable. We should consider that as

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 2:01 AM, Jonathan Hull wrote: > > >> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> More generally, we need to move access control away as far away from >> filesystems as possible. One day, the compil

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

> Hi all, > > Here’s a draft proposal following > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html>. > The idea is simplify Swift’s syntax

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution > wrote: > > More generally, we need to move access control away as far away from > filesystems as possible. One day, the compiler is going to get ported over > to a platform with some bonkers rules that are going to turn aro

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

We avoid forcing users to organize code in such an opinionated manner just to please the compiler. Perhaps some submodules deserve a separate file, but I think that choice should not be forced by the language. I don’t have data on the popularity, but I personally very much dislike the similar re

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

Hello list, Matthew Johnson and I have been putting our proposals together towards a joint “let’s fix private access levels” proposal. As the community seems quite divided on the issue, we offer two solutions in our proposal to let the community debate and to let the core team make the final de

Re: [swift-evolution] [Discussion] Variadics as an Attribute

This was my first thought as well: imho it doesn't make sense to discard a good idea because of a vague hope that there might be something better (in, I'd expect, two or three years from now…). I feel the same way. Currently, Swift’s variadic parameters are just a way to call a function witho

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This was syntax I initially considered, but Jaden swayed me with the idea that we already have an `extension` keyword so we may as well use it to match the rest of the language. Repeating the `module` declaration also lends itself more to C++-style namespaces, which these are not. I’m not sayi

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

The one thing i don't understand is the point of using extensions to extend modules across multiple files, why not just allow declaring the submodule in multiple files? > Le 20 févr. 2017 à 22:48, Jaden Geller via swift-evolution > a écrit : > > Oh, I see. You’re questioning the motivation of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Part of it. My concern is that the brackets will push everything in the file to the right. My question is: What do we get in return for that? (as opposed to a system which acted on the whole file) Thanks, Jon > On Feb 20, 2017, at 10:45 PM, Jaden Geller wrote: > > Oh, you’re referring to t

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 1:46 AM, Jonathan Hull wrote: > > >> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote: >> >>> >>> >>> I would honestly love to see something which just maps modules to >>> folders/groups for simplicity sake. >>> >> >> There is no

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Oh, I see. You’re questioning the motivation of having scope-granularity submodules at all! My misunderstanding. I actually hadn’t considered this as added complexity. In my mind, a scoped module declaration seems more Swifty than a file module declaration. It builds on the existing syntax in S

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 6:44 PM, Robert Widmann wrote: > >> >> >> I would honestly love to see something which just maps modules to >> folders/groups for simplicity sake. >> > > There is nothing about this scheme that prevents you from organizing your > code this way. However, modulo that p

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 11:39 PM, Matthew Johnson wrote: > > Thanks for bringing up submodules Robert. I agree it's a good time to > discuss them. > > There seem to be two broad approaches to submodules. One is more of a > physical / encapsulation based view and the other is more of a logic

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Oh, you’re referring to the fact that a submodule under this proposal must be contained within braces? It would be purely additive to, in the future, annotate that the outer scope of a file is part of some given submodule. Consider the following the following straw-man syntax that might be equiv

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

The same benefits afforded by multiple extensions contained in the same file: sometimes you wish for your concerns not to overlap with one another, but feel that they do not necessarily warrant being split into separate files. There really isn’t a reason we should enforce separation of submodul

[swift-evolution] [Proposal Draft] Remove open Access Modifier

Hi all, Here’s a draft proposal following https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html. The idea is simplify Swift’s syntax by getting rid of the `open` access modifier. A rendered version of the proposal is available here: https://github.com/kyouko

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

I think my question is: Why do we want to allow submodules that are smaller than a file? What does that give us to offset the added complexity? Thanks, Jon > On Feb 20, 2017, at 6:44 PM, Robert Widmann wrote: > > >> On Feb 20, 2017, at 9:36 PM, Jonathan Hull > > wrote:

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 6:42 PM, Jaden Geller wrote: > > Jon, > > I think we might have miscommunicated. It is intended that outermost module > is implicit; no `module` declaration is required to wrap every file. We tried > to show this in the first code snippet. > > What do you mean “covering

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

Damn, there seems to be no better way to create reactions than saying something stupid ;-) - to bad the reactions tend to focus on the stupidity in this case... It should have been "union" instead of "sum", so basically having Optional modeled as (T | Void) > Enums in Swift *are* sum types. Ther

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

> On Feb 20, 2017, at 4:15 PM, Joe Groff wrote: >> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> It’s expected that if y

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

> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution > wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted in identifiers and which in

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Thanks for bringing up submodules Robert. I agree it's a good time to discuss them. There seem to be two broad approaches to submodules. One is more of a physical / encapsulation based view and the other is more of a logical / namespace based view. This proposal falls into the latter group

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

> On Feb 20, 2017, at 10:04 AM, Joanna Carter via swift-evolution > wrote: > > Otherwise known in my language as : > > public - anywhere > internal - anywhere inside the module > private - only inside current type > extensible - in current file and in subtypes/extensions in other files > > Th

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad > On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. > > *** > > Any group of S

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

To further clarify—I think it would be accurate to say that this proposal introduces 2 things: 1) submodules, without changing the existing module system 2) `public` keyword for re-exporting modules It is both unnecessary and not allowed to name the outermost module in the file. The `module` ke

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 9:36 PM, Jonathan Hull wrote: > > What is the rational for having modules covering only part of a file? > Wouldn’t it be less clutter to have an annotation which worked for the whole > file. At the very least it would be nice to have an option to spell it in a > way th

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Jon, I think we might have miscommunicated. It is intended that outermost module is implicit; no `module` declaration is required to wrap every file. We tried to show this in the first code snippet. What do you mean “covering only part of a file”? Cheers, Jaden Geller > On Feb 20, 2017, at 6:

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

What is the rational for having modules covering only part of a file? Wouldn’t it be less clutter to have an annotation which worked for the whole file. At the very least it would be nice to have an option to spell it in a way that applies to the whole file. Otherwise, everything will be inde

Re: [swift-evolution] [Pitch] Let's talk about submodules

That’s an interesting proposal. Here are the issues I see: - I don’t like nesting everything within a large “module” block. I would like a top-level “@module Foo” declaration for the entire file. Also, since any sub-modules would be nested within the implicit top-level module, I’d prefer the ke

[swift-evolution] [Proposal][Discussion] Modular Swift

Good Evening All, Jaden Geller and I have been considering a (sub)module system for Swift that would complement the existing language but also provide sorely needed modularity. A draft of the proposal is attached to this email, but it can also be read as a gist

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

On Mon, Feb 20, 2017 at 12:29 PM, Alex Blewitt wrote: > > On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change fo

Re: [swift-evolution] Dictionary Enhancements

> On Feb 20, 2017, at 10:19 AM, Ben Cohen wrote: > > As it is right now, that wouldn’t distinguish it since Sequence.filter on > Dictionary can already take a (Key,Value)->Bool transformation since > (Key,Value) is the Element type: > let d = [1:"1"] > let f: (Int,String)->Bool = {_,_ in true }

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

> On Feb 20, 2017, at 1:53 PM, Matthew Johnson wrote: > >> >> On Feb 20, 2017, at 3:22 PM, Joe Groff > > wrote: >> >>> >>> On Feb 20, 2017, at 1:04 PM, Matthew Johnson >> > wrote: >>> On Feb 20, 2017, at 2:38 PM, Joe Groff >>

Re: [swift-evolution] [Pitch] Let's talk about submodules

You’ll be delighted to know, then, that I’ve been thinking about this for a few weeks now and have a draft proposal that will be submitted for discussion shortly. I believe this can be an additive feature and still preserve all the goodness you would expect of a real module system. ~Robert Wid

Re: [swift-evolution] [Pitch] Let's talk about submodules

Oh, I thought this would be another discussion about namespaces. On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon > wrote: > > > > Okay, lots of people want to have some kind of submodule

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. Ten seconds after sending this, I realized I forgot an important cav

[swift-evolution] [Pitch] Let's talk about submodules

Okay, lots of people want to have some kind of submodule feature, so I'd like to sketch one out so we can hopefully agree on what submodules might look like. *** Any group of Swift files can be grouped together to form a submodule. Submodules belong within a particular module, and have a dotted

Re: [swift-evolution] 'Public' class visibility specifiers

I've thought about how to deal with override in a way that is consistent with the language. Maybe something like this? // publicly visible but can't be subclassed. public private(subclass) // publicly visible and may be subclasses within the module. The default public internal(subclass) // publi

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> > Well I was rather thinking of making a Swift-only library (at least at first) > but that would also be available for other platforms e.g Linux or maybe some > day on Windows => also working with reduced performance without the > Accelerator Framework but leveraging it on Apple Platforms (an

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

I like how the Enum version looks @objc enum Planet: String {} But it looks odd for structs @objc struct Planet: String {} What do you think we should use? On Mon, Feb 20, 2017 at 8:05 PM Derrick Ho wrote: > Swift Enum strings should not translate into objective c global static > strings. > >

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

Just playing devil’s advocate for a second: What if, instead of having an explicit annotation, we make a simple rule to break ambiguity. That is, if the type is unambiguous, we use that, and if it is ambiguous, we use the first one (as defined by the creation/definition order). Then we have an

Re: [swift-evolution] Compile-time generic specialization

Sorry, I forgot to copy in its definition: typealias T = Tensor As a quick sanity check I changed all `T.` syntax to `Tensor` and got the same behavior. Thanks! > On Feb 20, 2017, at 3:58 PM, David Sweeris wrote: > > > On Feb 20, 2017, at 12:23, Abe Schneider via swift-evolution > mailto:s

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

Swift Enum strings should not translate into objective c global static strings. As I wrote in my proposal ( https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md ) , we need to support a failable initializer. I chose @objcst

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

> On Feb 20, 2017, at 6:54 PM, Michel Fortin wrote: > >> >> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : >> >> >>> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : > > On Feb 20, 2017, at 1:42 PM, Mi

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

It might have been suggested (this discussion is huge), but I think private could just be defined more or less like a combination of Swift 3 fileprivate and private with one little twist - it is also accessible from extensions in other files internal to the defining module. Module 1 File A.swif

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

> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : > > >> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >> >>> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: > Le 20 févr. 2017 à 14:23, Charles Srs

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

> Le 20 févr. 2017 à 17:56, David Sweeris a écrit : > > Could we only infer purity for one “level”? As a technical limitation rather > than part of the language spec, to be removed at some later date when we have > time to implement the diagnostic logic? So in your example, the purity of > fun

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

Agree. If technical limitations do not prohibit it, Kevin's idea seems the more elegant. On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution < swift-evolution@swift.org> wrote: > I don’t think we need/want to add `@objcstring` or anything like that, but > I do think we should le

Re: [swift-evolution] Strings in Swift 4

Hi Ted, While Character is the Element type for String, it would be unsuitable for a String’s implementation to actually use Character for storage. Character is fairly large (currently 9 bytes), very little of which is used for most values. For unusual graphemes that require more storage, it al

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

I don’t think we need/want to add `@objcstring` or anything like that, but I do think we should let String enums be @objc (currently it’s int types only) and imported as const refs. // Already works @objc enum IntEnum: Int { case foo = 1 case bar = 2 } // "not an integer type" // Should

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

> On 21 Feb 2017, at 01:00, Xiaodi Wu via swift-evolution > wrote: > > I'm terribly sorry to be _that guy_, but I have to interject that > `private(file)` was discussed extensively during review for SE-0025, that the > full scheme laid out in the first message of this thread was given > cons

[swift-evolution] [pitch] Make swift enum string available to Objc

Swift should not forsake objective-c. At least not when it comes enum strings. Although swift enums are suppose to be swift only, I think we should add a new attribute to slightly relax that. I think a good attribute would be @objcstring. By adding @objcstring, an objective-c exclusive class wi

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

I'm terribly sorry to be _that guy_, but I have to interject that `private(file)` was discussed extensively during review for SE-0025, that the full scheme laid out in the first message of this thread was given consideration, and that the core team took these suggestions into account before accepti

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

2017-02-21 1:21 GMT+03:00 Matthew Johnson : > > Thanks for the links. I scanned through them somewhat quickly and didn’t > see anything that specifically said `Never` should conform to all > protocols. Did you see that specifically? I only saw mentions of it being > a bottom type and therefore a

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

That is certainly a pragmatic solution. However, it would seem to me that it defeats the raison d'etre for the proposal. As I understand it, the whole idea here is that enum associated values work like argument lists, but the syntax is subtly different. Therefore, let's make the rules the same. If

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> Once such a library were reasonably mature, it would be reasonable to propose it for inclusion in swift proper. I expect this process will take a couple *years*. Yes, I do not expect this to come very quickly either but if no one gets started, that is going to last for even longer ;-) > or the

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

> On 19 Feb 2017, at 21:04, Anton Zhilin wrote: > > 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 dec

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

> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> It’s expected that if you need resilience, then you will throw an “open”

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

> On Feb 20, 2017, at 4:50 PM, Michel Fortin > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson > > a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin >> > wrote: >>> Le 20

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

> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : I’m not sure how I f

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

> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : > >> >> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: >> >>> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit >>> : >>> >>> I’m not sure how I feel about that, since it hamstrings the ability to >>> improve APIs in a lot of ways wit

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

> On Feb 20, 2017, at 11:14 AM, Anton Zhilin wrote: > > 2017-02-20 18:23 GMT+03:00 Matthew Johnson >: > > > > >> On Feb 20, 2017, at 3:58 AM, Anton Zhilin > > wrote: >> But that raises another concern. In a previous discussion, i

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 20, 2017, at 4:55 PM, Florent Bruneau > wrote: > > >> Le 20 févr. 2017 à 18:22, John McCall a écrit : >> >>> >>> On Feb 20, 2017, at 3:40 AM, Florent Bruneau >>> wrote: >>> >>> Hi John, >>> >>> I've spent 3 hours reading the manifesto and its really very interesting. >>> Despi

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

> On Feb 20, 2017, at 9:09 AM, David Hart via swift-evolution > wrote: > > >> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I'm developing an application where we use RxSwift heavily. RxSwift is a >> stream library. Conseque

Re: [swift-evolution] [Manifesto] Ownership

> Le 20 févr. 2017 à 18:22, John McCall a écrit : > >> >> On Feb 20, 2017, at 3:40 AM, Florent Bruneau >> wrote: >> >> Hi John, >> >> I've spent 3 hours reading the manifesto and its really very interesting. >> Despite the completeness of the included discussion, I have a few >> comments/

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 20, 2017, at 3:38 PM, John McCall wrote: > >> On Feb 20, 2017, at 4:26 PM, Matthew Johnson > > wrote: >>> On Feb 19, 2017, at 11:24 PM, John McCall >> > wrote: >>> On Feb 18, 2017, at 11:08 AM, Matthew Johnson >>>

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

> On Feb 20, 2017, at 3:22 PM, Joe Groff wrote: > >> >> On Feb 20, 2017, at 1:04 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 20, 2017, at 2:38 PM, Joe Groff >> > wrote: >>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson vi

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

> On Feb 20, 2017, at 3:46 PM, Karl Wagner wrote: >> On 20 Feb 2017, at 18:57, John McCall > > wrote: >> >>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> It’s expected that if you need resilience, then

Re: [swift-evolution] Sequence/Collection Enhancements

> On Feb 20, 2017, at 7:38 AM, Ole Begemann wrote: > >> >> On 17 Feb 2017, at 01:39, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi swift-evolution, >> >> Following up on Ted’s post regarding the opening up of stage 2, I’m starting >> a thread to discuss

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 20, 2017, at 4:26 PM, Matthew Johnson wrote: >> On Feb 19, 2017, at 11:24 PM, John McCall > > wrote: >> >>> On Feb 18, 2017, at 11:08 AM, Matthew Johnson >> > wrote: >>> Hi John, >>> >>> This is fantastic! I’ve been eagerly anti

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 19, 2017, at 11:24 PM, John McCall wrote: > >> On Feb 18, 2017, at 11:08 AM, Matthew Johnson > > wrote: >> 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

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

> On Feb 20, 2017, at 1:04 PM, Matthew Johnson wrote: > >> >> On Feb 20, 2017, at 2:38 PM, Joe Groff > > wrote: >> >>> >>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Feb 20, 2017,

Re: [swift-evolution] Strings in Swift 4

Hi Ben, Dave (you should not read this now, you’re on vacation :o) & Others As described in the Swift Standard Library API Reference: The Character type represents a character made up of one or more Unicode scalar values, grouped by a Unicode boundary algorithm. Generally, a Character instance

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

> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution > wrote: > >> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> It’s expected that if you need resilience, then you will throw an “open” >> enum. Essentially, we pass res

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

> On Feb 20, 2017, at 2:38 PM, Joe Groff wrote: > >> >> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Compile-time generic specialization

> On Feb 20, 2017, at 12:23, Abe Schneider via swift-evolution > wrote: > > However, if I define an operation to on the Tensor: > > class SomeOp { > typealias StorageType = S > var output:Tensor > > init() { > output = Tensor(size: 10) > } > > func apply()

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

> On 20 Feb 2017, at 18:57, John McCall wrote: > >> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> It’s expected that if you need resilience, then you will throw an “open” >> enum. Essentially, we pass resilience of typed throws on

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

> On Feb 20, 2017, at 12:07 PM, Tino Heth via swift-evolution > wrote: > > Obviously, this won't become an accepted proposal - neither the time nor the > author would be appropriate for such a result. > But the list seems a little bit bored lately, so maybe a relaxed discussion > without pra

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

> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I'd like to discuss the possibility of treating the cases of a given enum as >> if they ar

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

A lot of problems look algebra-like. Best to have sums and products at your disposal. Cheekily, ~Robert Widmann 2017/02/20 15:07、Tino Heth via swift-evolution のメッセージ: > Obviously, this won't become an accepted proposal - neither the time nor the > author would be appropriate for such a r

Re: [swift-evolution] Compile-time generic specialization

Sorry, just following up with a few more thoughts. > > I consider Java’s type erasure to be orthogonal to the > overloading/customization point issue, but of course I agree that it’s > surprising. While the underlying reason may be different, Swift has a similar potential for surprise with g

[swift-evolution] [Fake-Proposal] Remove enums with associated objects

Obviously, this won't become an accepted proposal - neither the time nor the author would be appropriate for such a result. But the list seems a little bit bored lately, so maybe a relaxed discussion without practical implications isn't the worst thing to have now ;-) Several current threads se

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

> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution > wrote: > >> >> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution >> mailto:swift-evolution@s

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

> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: > >> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : >> >> I’m not sure how I feel about that, since it hamstrings the ability to >> improve APIs in a lot of ways without breaking backwards compatibility. A >> quick example off the top o

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

> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : > > I’m not sure how I feel about that, since it hamstrings the ability to > improve APIs in a lot of ways without breaking backwards compatibility. A > quick example off the top of my head would be all the Cocoa APIs that started > out havi

  1   2   >