Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution > a écrit : > > On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about the new #unknown behavior. Is it intended to be used fo

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I think `unknown` should be a modifier for either `case` or `default`. This would allow: unknown default: unknown case _: // similar to default unknown case (1, _): // enum in second position If the case can be reached with statically known enum values, the compiler gene

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Le 5 déc. 2017 à 0:43, C. Keith Ray via swift-evolution > a écrit : > > BTW, Java via JNI would be another good application of this proposal. I once > used a JNI wrapper library in C++ and it was pretty hairy and tedious. Most people would expect Java language bindings to be strongly typed.

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Le 2 déc. 2017 à 12:20, Chris Lattner via swift-evolution > a écrit : > >> *At worst*, you invoke the tool from the command line to build the Swift >> module that corresponds to a given Python module. >> >> py2swift >> >> We could absolutely introduce tooling hooks to make the compile

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> Le 20 nov. 2017 à 21:22, Chris Lattner a écrit : > >> On Nov 16, 2017, at 4:49 AM, Michel Fortin via swift-evolution >> wrote: >> >> I think this protocol and its subscript need a better name. From a user of >> the class point of view, the subsc

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Key paths could be made to work by implementing the protocol in terms of retrieving key paths instead: protocol SupplementalKeyPathDispatching { associatedType KP: PartialKeyPath static func supplementalKeyPath(for name: String) -> KP } and in your implementation of PyVal: exten

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

I think this protocol and its subscript need a better name. From a user of the class point of view, the subscript looks like you can retrieve the members of the class, whereas in reality you'll only get the ones you have manually implemented. Even methods and properties having the `dynamic` attr

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Oh right. I guess that makes most of my review beside the point then. Sorry. > Le 11 nov. 2017 à 14:46, BJ Homer <mailto:bjho...@gmail.com>> a écrit : > > > >> On Nov 11, 2017, at 9:49 AM, Michel Fortin via swift-evolution >> mailto:swift-evolution@swift.or

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? One thing to keep in mind is that flatMap is basically the equivalent of optional chaining for non-`self` parameters. let result = character?.hexValue // optional chaining let result = character.flatMap { hexValue($0) } // option

Re: [swift-evolution] Figuring out what you get for free

17 at 7:32 PM, Michel Fortin via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> I found that for Sequence, but Sequence is far f

Re: [swift-evolution] Figuring out what you get for free

> Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution > mailto:swift-evolution@swift.org>> a écrit : > > I found that for Sequence, but Sequence is far from the only protocol with > default implementations, and not all of them have maintainers willing to > write and update documentatio

Re: [swift-evolution] [Concurrency] A slightly different perspective

The first implementation I proposed before Wallacy suggested using dispatch_group_t does not involve any dispatching. It's possible that loadWebResource would dispatch in the background, but dispatching is not necessary either. For instance, loadWebResource could just be a wrapper for CFNetwork

Re: [swift-evolution] [Concurrency] A slightly different perspective

> Le 4 sept. 2017 à 10:01, Wallacy via swift-evolution > a écrit : > > func processImageData1a() async -> > Image { > let dataResource = async loadWebResource("dataprofile.txt") > let imageResource = async loadWebResource("imagedata.dat") > > // ... other stuff can go here to cover l

Re: [swift-evolution] [Concurrency] async/await + actors

> Le 19 août 2017 à 11:38, Matthew Johnson a écrit : > > > > Sent from my iPad > > On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>>> For instance, has Array value semantics? >&g

Re: [swift-evolution] [Concurrency] async/await + actors

>> For instance, has Array value semantics? > > By the commonly accepted definition, Array does not provide value > semantics. > >> You might be tempted to say that it does not because it contains class >> references, but in reality that depends on what you do with those UIViews. > > An aspect

Re: [swift-evolution] [Concurrency] async/await + actors

Great writeup. Here's a few comments about the manifesto, actors and value semantics specifically. # About actors and data isolation Can I call global functions like sin(x) in an actor? Surely you need to be able to do that. But how can the compiler know which functions are safe to use and wh

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md > What is your evaluation of the proposal? It's a bit hard to evaluate without experience. But I would summarize the benefits like this: 1. Clearer semantics inside functions. Variables t

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

> Le 26 avr. 2017 à 18:33, Xiaodi Wu a écrit : > > On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Just throwing a idea that came to me while reading this discussion (hopefully > not duplicating so

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

Just throwing a idea that came to me while reading this discussion (hopefully not duplicating something that was already suggested)... We could introduce `FiniteFloat` and `FiniteDouble` types that would disallow NaN and infinity. Computations creating NaN or infinity would trap with these type

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

> Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > What is your evaluation of the proposal? I don't understand the need for this: when you need things to be accessible elsewhere in the file y

Re: [swift-evolution] Type-based ‘private’ access within a file

> Le 5 avr. 2017 à 11:30, Chris Lattner a écrit : > > On Apr 5, 2017, at 5:13 AM, Michel Fortin > wrote: >> >>> Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> a écrit : >>> >>> - fileprivate should really beco

Re: [swift-evolution] Type-based ‘private’ access within a file

> Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution > a écrit : > > - fileprivate should really become much more rare, which makes it more > meaningful and significant where it occurs. This was the original idea and > intent behind SE-0025. I think this will end up being a flawed ass

Re: [swift-evolution] [Rejected] SE-0159: Fix Private Access Levels

> Le 3 avr. 2017 à 16:20, John McCall via swift-evolution > a écrit : > >> I hope the core team will reconsider the spelling change to “private” and >> “scoped”. > > We won't. I find that unfortunate, but it's good to be fixed. I recently replaced every instance of `private` by `fileprivate`

Re: [swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

I think you forgot to consider hexadecimal floating point literals. Those have a power-of-2 significand (instead of power-of-10). They can't be expressed by the `ExpressibleByArbitraryPrecisionFloatLiteral` protocol you're proposing. > Le 30 mars 2017 à 17:56, David Hart via swift-evolution >

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> Le 23 mars 2017 à 12:03, Matthew Johnson via swift-evolution > a écrit : > > I think it’s likely that a non-trivial degree of any confusion is related to > the mistake we made in choosing the names. Both `fileprivate` and `private` > include the word `private` in their name. If we had left

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> * What is your evaluation of the proposal? Good. I'll certainly appreciate the added clarity of knowing which methods are exposed to Objective-C. Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The motivation section says that this will reduce the reduce the binary s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> • What is your evaluation of the proposal? Renaming `fileprivate` to `private` makes sense. In my code, I use `fileprivate` and `private` interchangeably, meaning that I write `private` for things that shouldn't be leaked to the whole module and if by chance the compiler complain I'll c

Re: [swift-evolution] [Manifesto] Ownership

> On 6 mars 2017, at 15:53, John McCall via swift-evolution > wrote: > > Class types have reference semantics and are still copyable; ownership is not > going to change that. More generally, I don't see how anything we can do in > ownership could ever do something like eliminate the possibili

Re: [swift-evolution] [Draft] Really Simple Submodules

>> <mailto:devteam.cod...@gmail.com>> wrote: >>> >>> This proposal strikes me not as a submodules proposal, but as a sneaky way >>> to add 'friend' to Swift. It is conceptually simpler because it doesn't >>> address modularity at al

Re: [swift-evolution] [Draft] Really Simple Submodules

large teams want to use submodules to structure > their code base, some level of hierarchy is imo necessary. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.

Re: [swift-evolution] [Draft] Really Simple Submodules

> On 5 mars 2017, at 22:28, Robert Widmann wrote: > > This proposal strikes me not as a submodules proposal, but as a sneaky way to > add 'friend' to Swift. It is conceptually simpler because it doesn't address > modularity at all! > > ~Robert Widmann >

[swift-evolution] [Draft] Really Simple Submodules

Sorry for introducing yet another submodule proposal out of the blue. I'm a bit surprised at how far-reaching the various submodule proposals floated on this list have been. Directories, access controls, @exported imports... For comparison's sake here's one that is *really* simple and short I wr

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

> Le 21 févr. 2017 à 22:05, Matthew Johnson a écrit : > >>> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : >>> e) Generic Containers: Generic containers that impose requirements on their elements will pose some additional problems, for instance: `Set.insert` needs to call

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

(this was accidentally sent off-list, reposting here a day later) > Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : > >> e) Generic Containers: >> Generic containers that impose requirements on their elements will pose some >> additional problems, for instance: `Set.insert` needs to call `h

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] 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] [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

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

> Le 20 févr. 2017 à 13:42, Charles Srstka a écrit : > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> wrote: >> >> a) Structs/Locals: >> Structs and local variables behave similarly. You can access `let` and `var` >> propert

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

nd `Dictionary` cannot be pure. I feel enforcement for (c) and (d) needs to be implemented first if you are to implement `pure` this way so you aren't over-reliant on vouching at every corner. Perhaps you won't even need a vouching mechanism once that's done. > Le 20 févr.

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

Le 20 févr. 2017 à 1:19, David Sweeris a écrit : > > On Feb 19, 2017, at 21:19, Xiaodi Wu wrote: > >> This is very, very interesting. Thank you so much for the text. >> >> If I understand your take correctly, the benefits of `pure` in Swift would >> be contingent on how pervasively it can be

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

swift-evolution > mailto:swift-evolution@swift.org>> wrote: > 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

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 allowe

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, but it's possible that we'l

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. let something = make

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

I'm just going to point out to the documentation about pure functions in the D language which has an unusual but very practical take on enforcing purity. It's interesting, and it might also provide a list for things that might need be addressed in this proposal. https://dlang.org/spec/function.h

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 10:52, Matthew Johnson a écrit : > > >> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution >> wrote: >> >> >>> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >>> a écrit : >>> >

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution > a écrit : > > On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: >>> The beauty of Swift 2's access modifiers was that they were based >>> around files and modules, explicitly rejecting types and scopes as >>> units for dete

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

Le 12 févr. 2017 à 12:24, Chris Lattner via swift-evolution a écrit : > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > wrote: >> Fileprivate >> >> I started the discussion early during the Swift 4 timeframe that I regret >> the change in Swift 3 which introduced a scoped pr

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 11 avr. 2016 à 14:36, Dave Abrahams a écrit : > 3. The fact that we're migrating C-style for loops to > uses of stride, as noted in https://github.com/apple/swift/pull/2125, > has convinced me that, sadly, we may need an answer that doesn't > involve ranges. But maybe something like >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 10 avr. 2016 à 13:06, Dave Abrahams via swift-evolution a écrit : > > on Sun Apr 10 2016, Michel Fortin wrote: > >> Le 10 avr. 2016 à 6:17, Brent Royal-Gordon via swift-evolution >> a écrit : >> >>> Remember, conditional branches are relatively slow, and we want to >> avoid them where we

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 10 avr. 2016 à 6:17, Brent Royal-Gordon via swift-evolution a écrit : > Remember, conditional branches are relatively slow, and we want to avoid them > where we can. If this is, for instance, the test of a loop, the extra branch > is not a good thing. Perhaps it's a bit extreme, but my ide

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 9 avr. 2016 à 13:23, Xiaodi Wu a écrit : > The sign of the stride size is already (in the current version of Swift) > evaluated in the stride generator/iterator; as written, it is evaluated every > time next() is called, but of course that is optimized away when possible. You're right. I ha

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 9 avr. 2016 à 4:25, Xiaodi Wu a écrit : > Note that it's not possible to write 9...0. Once that is clear, it's > fairly intuitive (IMO) to look to the stride size for indicating the > direction in which we stride, since that is the only other value there > is. I know it's not possible to write

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution a écrit : > > (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1] The above reads wrong to me. The expression has to be read differently depending on the tinny detail that is the sign of the step that comes last: * positive step: from 0 to 9 s

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

> What is your evaluation of the proposal? I don't like "form" as a prefix. To me there is no difference between `union` and `formUnion`: both sounds functional-style, and actually the second one perhaps a bit more to my ears. There's basically two dictionary definitions of "form": 1. "bring t

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Or maybe we could just abolish of file-private. It's not like it'd be 100% gone: private declarations at the root of a file will always be equivalent to file-private. For non-root things that need to be accessible within the file you can use `internal`, which is more accessible than before but s

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

> * What is your evaluation of the proposal? I don't like that proposal as it stands currently. By the way, I don't use any IUO in my code, except sometime for @IBOutlets. I do encounter them sometime with external APIs, but the way they work in Swift 2 isn't causing me any problem. They are al

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution a écrit : > > afaics this is the third time someone mentions that "file-private" is > uncommon — so I think it's time someone dissents: I'll do the same. There's many instances in my code where I rely on the file-private behavior of Swift

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

Le 20 mars 2016 à 16:26, Tyler Fleming Cloutier via swift-evolution a écrit : > > Would it be wise to allow force conversion for the cases in which the > developer believes the match is exhaustive? ie > > do { > let action = chooseAction(game) > game = try game.applyAction(action) > }

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> Le 17 mars 2016 à 21:59, Jordan Rose via swift-evolution > a écrit : > > > Open > Issue: UnsafeBufferPointer > > The type UnsafeBufferPointer represents a bounded typed memory region with

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Le 15 mars 2016 à 20:31, Michael Ilseman a écrit : > Automatic inference, at least in the near term, will not be turned on by > default for all C APIs, but will start out as opt-in. In the near term, > heuristics and techniques are tuned for CF-style naming conventions. Future > work could be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> What is your evaluation of the proposal? I worry about imported libraries. I think the default is right for code that was written directly in Swift, but for C and Objective-C code that was written in discartable-by-default environment, the APIs were designed with discardable results that in m

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

This is an interesting proposal. I have a couple of throwing `setSomething` methods in my code that could be expressed as throwing property setters. That said, I don't really mind them being methods. Methods having a verb in their names makes them fit well with `try` at the call site. I also h

Re: [swift-evolution] Two-for-Tuesday: Resettable Properties

Le 15 mars 2016 à 9:49, Patterson, Jason via swift-evolution a écrit : > There were a few ideas here but I ultimately settled on a new `set?` > operator. The proposal then details the usage and ramifications of > such a change. For example, the getter would continue to return `T` > while the typ

Re: [swift-evolution] [META] Re: Mailman?

Le 15 mars 2016 à 12:52, Joe Groff via swift-evolution a écrit : > > I can't speak for the whole core team, but my preferences would be for > something that supports offline access well, like a mailing list, can sync > read and replied state across clients, like IMAP, but still provides > low

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> What is your evaluation of the proposal? Looks like a very good idea. Less wrapper code means less possibility of an error, a less cluttered call stack when debugging, and faster compile times (because of less code). It looks like it'll work well for importing Apple headers. I'm a bit worried

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> To summarize the place we’d like to end up: > > - “public” -> symbol visible outside the current module. > - “internal” -> symbol visible within the current module. > - unknown -> symbol visible within the current file. > - “private” -> symbol visible within the current declaration (class, > ex

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution a écrit : > I would like to write like this: > > UIView.animateWithDuration(0.3, > > animations: { () -> Void in > // animation code here > }, > completion: { Bool -> Void in > // completion code here > } >

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution a écrit : > As I recall it, there is no overlap between operator characters and > identifier characters. If it's not in the operator set, it's effectively > reserved for identifiers. It's funny that ¢, £, and ¥ are operator characters

Re: [swift-evolution] Better syntax for deferred?

Le 2 janv. 2016 à 13:29, Maury Markowitz via swift-evolution a écrit : > No, they don't. With the exception of "Go", I'm unfamiliar with any other > language that implements this feature *in this fashion*. D has `scope (exit)`, which is exactly the same as `defer` in Swift. It's also common t

Re: [swift-evolution] Better syntax for deferred?

Le 2 janv. 2016 à 9:25, Maury Markowitz via swift-evolution a écrit : > I'm confused about 'defer'. Not the purpose, the chosen syntax. > > func confusing() { >print("1") >defer { print("2") } >print("3") > } > > Produces 1,3,2. Trying to describe what is happening here is non-tri

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution a écrit : > On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote: >> Another possibility I've thought of is defining `defer { val }` to guarantee >> that val remains alive until the defer fires on scope exit. That might let >> us leave `d

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

For reference, I'll just point out that there was an interesting discussion about this topic at the beginning of December. https://lists.swift.org/pipermail/swift-evolution/2015-December/000233.html -- Michel Fortin https://michelf.ca ___ swift-evolut

Re: [swift-evolution] rename dropFirst() and dropLast()

Le 28 déc. 2015 à 19:25, Kevin Ballard a écrit : > To add to this, existing Swift and Obj-C precedent says the mutating method > will be named with "remove" (e.g. `removeFirst`). So the logical name for > this based on the grammar rule is `removingFirst`, but that also sounds weird > to me. S

Re: [swift-evolution] rename dropFirst() and dropLast()

Le 28 déc. 2015 à 19:02, Kevin Ballard via swift-evolution a écrit : > On Mon, Dec 28, 2015, at 03:53 PM, Michel Fortin via swift-evolution wrote: >> Following the new API guidelines, shouldn't the name be either >> `droppingFirst` or `excludingFirst`? That would solve

Re: [swift-evolution] rename dropFirst() and dropLast()

Le 28 déc. 2015 à 17:27, Daniel Duan via swift-evolution a écrit : > .dropFirst() => .excludeFirst() > > What do y’all think? Following the new API guidelines, shouldn't the name be either `droppingFirst` or `excludingFirst`? That would solve your problem, right? Many things still need to be

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution a écrit : > Even with backticks would not be possible. > > You may need to reference the method signature altogether. > > var someA = A() > let fn1 = someA.#someFunc(a: Int) -> Int > let fn2 = someA.#someFunc(a: Int) -> Double > let fn3 = so

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

inferredtype -- Michel Fortin https://michelf.ca ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

Le 23 déc. 2015 à 13:36, Matthew Johnson a écrit : > >> I'm not sure why you say the last two should be addressed separately from >> the "production" language. Are you proposing Swift should come in multiple >> language variants? >> > > Not exactly. > > My point is that it is best to design

Re: [swift-evolution] [Proposal] Make `didSet` also available for `let` property, or something new such as `didInit`

Le 23 déc. 2015 à 11:07, Félix Cloutier via swift-evolution a écrit : > willSet and didSet are currently not even called from the init method. And they can't, because in those two blocks you have access to the old value as well as the new value. How would that work when you're setting the init

Re: [swift-evolution] Final by default for classes and methods

Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution a écrit : > > 3) Annoyance. Some consider it to be annoying to have to annotate a class > declaration in order to inherit from it. People stating this argument either > are either writing a lot of superclasses or are so bothered by

Re: [swift-evolution] Swift case conventions for Enums

Le 22 déc. 2015 à 10:27, Joe Groff via swift-evolution a écrit : > > For non-enum constants, we use lowerCamelCase, for example Int.max, or > UIColor.redColor. What about option sets? -- Michel Fortin michel.for...@michelf.ca https://michelf.ca __

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

Le 21 déc. 2015 à 21:34, Dave Abrahams via swift-evolution a écrit : > I’m actually coming around to wanting it to be just “type” as a contextual > keyword, if we can make that work. The point is that these types aren’t > “associated” in any way that distinguishes them from other requirements

Re: [swift-evolution] Final by default for classes and methods

Le 7 déc. 2015 à 14:18, Slava Pestov via swift-evolution a écrit : > Another idea we've discussed internally is some form of 'sealed' classes. > That is, classes that are publicly visible but only subclassable from within > their module. This could be used to define closed inheritance hierarch

Re: [swift-evolution] [Proposal] Property behaviors

Le 21 déc. 2015 à 12:23, Joe Groff via swift-evolution a écrit : > Some behaviors like `lazy` and `resettable` want to take control of the > storage to manage their semantics, but many behaviors are adapters > independent of how the underlying behavior behaves. These kinds of behavior > are e

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

Le 18 déc. 2015 à 15:22, David Farler via swift-evolution a écrit : > #if swift("2.2") > print("Hello") > #else > this code will not parse or emit diagnostics > #endif This is a change from how the #if directive currently works. Currently, it's a syntax error to write this: #if DEBU

Re: [swift-evolution] [Proposal] Property behaviors

Le 18 déc. 2015 à 18:56, Kevin Ballard a écrit : > On Fri, Dec 18, 2015, at 07:18 AM, Michel Fortin wrote: >> The reason I'm suggesting implementing synchronized as a behaviour instead >> of a type is because I found out with experience that synchronization should >> be related to variables, no

Re: [swift-evolution] [Proposal] Property behaviors

Le 17 déc. 2015 à 22:47, Kevin Ballard via swift-evolution a écrit : > Good point. I'm also inclined to say that Michel's motivating example (of a > property that requires going through a `synchronized` accessor) would be > better modeled just as a type Synchronized that exposes the > `synchr