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

True, adding the type would be redundant. Here is my revised solution. Which basically still allows you do use a different name besides newValue/oldValue set { let temperature = newValue // do stuff } didSet { let temperature = oldValue // do stuff } On Sun, Dec 4, 2016 at 12:47 AM Saagar Jha

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

oldValue is the value the property contained before didSet. self.value is the variable’s current value (i.e. newValue in willSet). Saagar Jha > On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution > wrote: > > -1. > > I always name parameters to code blocks

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

I’m along the lines of keeping the old behavior+warnings if “oldValue” is used for “newValue” and vice versa. Nonbreaking, and removes the issue of accidentally swapping the two. Saagar Jha > On Dec 3, 2016, at 7:33 PM, Derrick Ho via swift-evolution > wrote: >

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

-1. I always name parameters to code blocks with an "in" or "out" prefix, and want to maintain my ability to change the name for set. As to oldValue, isn't that the same as self.value? Does it even need to exist? > On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution >

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

I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a block-like syntax using $0 is nice, it fails to communicate whether it is a newvalue or an oldvalue. Therefore instead of following a block-like pattern it should follow a delegate-function like pattern. This would remove

Re: [swift-evolution] A proposal for inline assembly

I feel like inline assembly is a very niche idea. Inline assembly is supported by c and by extension objective-c. //file.h void aCFunction(); //file.m void aCFunction() { int a=10, b; asm ("movl %1, %%eax; movl %%eax, %0;" :"=r"(b) /* output */ :"r"(a) /* input */ :"%eax" /* clobbered register */

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

[Original pitch: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b ] GENERAL FEEDBACK I received a gratifying amount of feedback about my pitch here, on Twitter, through email, on several Slack channels, and on IRC. I

Re: [swift-evolution] A proposal for inline assembly

@Chris, I'm having trouble understanding your message. Do you mean that you hope to implement this soon, or that you don't intend to? @Félix, no, however I do think it would a good feature to have if you need to optimize certain lines of code beyond preset optimizer passes. On 12/3/16, Chris

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

@Xiaodi @Tino Apologies for my assumption that every developer already knows how to use Trello - the “lists” contain “cards” and the cards can be opened and you can add a more detailed description, comments, checklists, images, and other stuff. The thing you see in the list is just the

Re: [swift-evolution] A proposal for inline assembly

> On Dec 3, 2016, at 3:12 PM, Ethin Probst via swift-evolution > wrote: > > Hello all, > My name is Ethin and I am new to this community. However, I certainly > am no newbie when it comes to software development, and have emailed > all of you to file a proposal of

Re: [swift-evolution] A proposal for inline assembly

Do you have a use case for writing a whole assembly program in a .swift file rather than in an assembly file? > Le 3 déc. 2016 à 15:12, Ethin Probst via swift-evolution > a écrit : > > Hello all, > My name is Ethin and I am new to this community. However, I

[swift-evolution] A proposal for inline assembly

Hello all, My name is Ethin and I am new to this community. However, I certainly am no newbie when it comes to software development, and have emailed all of you to file a proposal of inline assembly in Swift. The assembly language would be within an asm {...} block. The asm keyword could also take

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

> An interesting format. Since it's a list, I'm not sure how to go about > commenting on the items already there with which I disagree. IMO, the format > doesn't lend itself to discussion. I have to agree… although I fear the major problem isn't the format, but rather the spirit: I guess tools

Re: [swift-evolution] [Discussion] Generic protocols

I'm not sure I understand. The first feature in the generics manifesto is parameterized protocols so that you can have, say, ConstructibleFrom and ConstructibleFrom and the ability to conform to the same protocol in two ways. The second feature is explained as a request for generalized

Re: [swift-evolution] [Discussion] Generic protocols

protocol Foo { associatetype Inner : SomeOtherProtocol } // Assuming String and Int conforms to SomeOtherProtocol protocol StringFoo : Foo where Inner == String {} protocol IntFoo : Foo where Inner == Int {} On Sat, Dec 3, 2016 at 13:57 Adrian Zubarev wrote: >

Re: [swift-evolution] [Discussion] Generic protocols

To which code ‘above’ do you refer exactly? --  Adrian Zubarev Sent with Airmail Am 3. Dezember 2016 um 20:29:05, Xiaodi Wu (xiaodi...@gmail.com) schrieb: On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution wrote: @Adrian, my comments inline below.

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

For those who are considering this topic, the existing document here is a good resource: https://github.com/apple/swift/blob/master/docs/AccessControl.rst Note that "class-only" and "protected" access levels are specifically called out as non-goals for Swift, with accompanying justification.

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

An interesting format. Since it's a list, I'm not sure how to go about commenting on the items already there with which I disagree. IMO, the format doesn't lend itself to discussion. For example, _why_ do you want friend classes? By contrast, it's been said on this list that not having them is

Re: [swift-evolution] [Discussion] Generic protocols

On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > @Adrian, my comments inline below. Hope this helps. > > On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < > adrian.zuba...@devandartist.com> wrote: > >> There is one thing that I want to point

Re: [swift-evolution] [Discussion] Generic protocols

@Adrian, my comments inline below. Hope this helps. On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > There is one thing that I want to point out with pitched syntactic sugar. > GenericMyProtocolName will also let you reuse T within a generic type, >

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

No idea if this will be useful, or if it will work, but I created a public trello board: https://trello.com/b/fmv4uV3n/swift-access-control - Pre-populated with a few of the things already mentioned. - There’s a link on the board to gain edit access. It’s possible this will be an utter

Re: [swift-evolution] [Discussion] Generic protocols

There is one thing that I want to point out with pitched syntactic sugar. GenericMyProtocolName will also let you reuse T within a generic type, where currently we cannot nest protocols into types. Even if we could, it’s not clear if nested declarations like protocol MyTProtocolName :

Re: [swift-evolution] [Discussion] Generic protocols

In general I'm very positive with the idea of generic protocols. This discussion is more about syntactic sugar, though I really like where it goes. Off topic: IMO, we should revisit approaches others already use for conflicts resolution. I personally tend to get something similar to Scala traits.

Re: [swift-evolution] [Discussion] Generic protocols

If I’m not mistaken here, extension Foo where T == Int will have an error of redeclaration foo anyways. --  Adrian Zubarev Sent with Airmail Am 3. Dezember 2016 um 15:22:56, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: extension Foo where T == Int { func foo() {

Re: [swift-evolution] [Discussion] Generic protocols

This is a different problem that protocols have today. There was some talk about having some sort of keyword like implements to disambiguate which from where the implementation comes from. Just pretend for a second, we wouldn’t have generic protocols and implement it the SE–01242 way:

Re: [swift-evolution] [Discussion] Generic protocols

> Why don’t we just use angle brackets to specify associated types? Protocols > aren’t using them for anything anyway. You normally don't want to specify all associated types that way — if you had to, Array would be declared like struct Array: SomeSequenceProtocol,

Re: [swift-evolution] [Discussion] Generic protocols

Ok. Let's say I have a generic protocol P with two methods: func foo() func bar(o:T) I have a default implementation of foo, which internally calls bar. How would work foo once a class implements P and P? On Sat, 3 Dec 2016 at 15:26 Adrian Zubarev via swift-evolution <

Re: [swift-evolution] [Discussion] Generic protocols

I believe generic protocols could be used as a shortcut for protocols with associated types. // Protocol with associated type protocol Foo { associatedtype F func foo(_ f: F) } // Existential typealias IntFoo = Any where F == Int struct Test : IntFoo {} // error struct Test :

Re: [swift-evolution] [Discussion] Generic protocols

This is called generalized existentials. It is included in the Generic Manifesto, has been discussed quite a few times with long email chains before, and spawned the change to the `protocol<>` syntax as kinda a precursor. It would be surprised if Swift 4 Phase 2 doesn't have it given its

Re: [swift-evolution] [Discussion] Generic protocols

Love it. I have one concern, though. How do we resolve conflicting associated types once several protocols get applied to a class or a struct? On Sat, 3 Dec 2016 at 11:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > I think I might found a solution that will satisfy

Re: [swift-evolution] [Discussion] Generic protocols

I think I might found a solution that will satisfy generic protocols and not break the system. The generics manifesto shows two features that are requested from generic protocols. The first feature is needed to reuse the same protocol multiple types like struct A : Proto, Proto. With SE–0142