Re: [swift-evolution] [Pitch] Rename Mirror

I also don't think this is a worthy change. Mirror can be extended or even changed in the future to become a true reflection base class. No benefits added and breaking code are to me a reason to not go forward with this. L On 21 July 2016 at 22:05, Anton Zhilin via swift-evolution

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

I don't see this as an issue and I'm sure not comfortable in being more verbose here or complicating the language unnecessarily. This is not a change that will bring either benefit or consistency as there are no other cases to compare the use of colon but these and variable declarations (which

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Matthew, I also thought that way but I think there is no harm in allowing one to create a subclass if there are no open methods in it, meaning there is no way a subclass can even replace an existing implementation. Even if Swift were to allow creating a new method with the same name of an existing

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On 21 July 2016 at 12:33, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access and > public overridability" begins now and runs through July 25. The proposal is > available here:

Re: [swift-evolution] [Proposal] Variadics as Attribute

I'm strongly opposed to this too. I'm not only not fond of the proposed syntax but I also don't really see how allowing other types in variadics will help anything. Also, there may be necessary more complex code to support all the extra (or even previously unknown) types that could be used with

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

ery language has one; we're just changing Swift's. L On 20 July 2016 at 16:05, Michael Peternell <michael.petern...@gmx.at> wrote: > >> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution >> <swift-evolution@swift.org>: >> >> Sealed

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I'm not very fond of this proposal at all as I don't believe there will be much gain with it (correct me if I'm wrong but libraries in Swift are monolithic and nothing to Java, where there is a benefit in doing this). That said, if this really has to go, Joe's syntax seems much cleaner but I'd

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

I like this syntax better. But do you guys think we could remove this "subscript" prefix? Could we actually bring subscripts closer to computed properties by doing something like "var self[externaName internalName : ParamType] : ElemenType"? That could also support the idea of creating named

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

On 20 July 2016 at 02:50, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The review of "SE-0122: Use colons for subscript declarations " begins now > and runs through July 24. The proposal is available here: > > >

Re: [swift-evolution] Throws, rethrows and declaration-modifiers in function declarations

I'm really really sure I don't want to see a `override throwing mutating func foo()` anywhere. Too much to read and no commas (please, I'm not saying this as a challenge!). Additionally, I think `overriden` would make the code much more english-readable and I'm still not proposing it. L On 19

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

On 18 July 2016 at 16:06, Károly Lőrentey <swift-evolution@swift.org> wrote: > On 2016-07-18 16:15:10 +, Leonardo Pessoa via swift-evolution said: > >> I believe sealed by default applied to functions makes the behaviour >> consistent with classes and allows for the

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

I believe this is not in discussion anymore. We're just debating some specifics now. L On 18 July 2016 at 18:33, John Randolph via swift-evolution wrote: > - infinity for this proposal. > > If adopted, it will mean that whenever I want to extend a class implemented

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Sealed methods can be overriden inside the defined module/library but not outside. Same benefit of classes. L On 18 July 2016 at 16:32, Garth Snyder via swift-evolution wrote: >> Nevin/Garth, please remember final and sealed are two different >> concepts: final

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Nevin/Garth, please remember final and sealed are two different concepts: final prevents anyone from subclassing/overriding while sealed prevents from subclassing/overriding *outside* the module they are declared. Thus final is not the same as sealed. L On 18 July 2016 at 15:45, Nevin

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Then we would need another keyword to close the method again should we need/want. public sealed override func foo() I don't see any association between override and open/sealed as they relate to two different aspects of class inheritance. One declares the method is overriding a superclass

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I'll also stick with "open" for both class and methods and I believe they should be required for both too. Just as I may not design a class to be subclassable outside my library, I may not want to allow a method to be overriden outside the library either (but I may want to override it inside the

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I'd agree with Doug, completely out of scope. The only way I'd support a goto statement was to jump to another switch case as in C#. L On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution wrote: > > On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I'll have to give this a -1. Code seems to be confusing with this new use of continue and we may easily lose control of the flow. If we are to allow another case to be executed, we should be able to explicitly direct the flow to the case we want. C# does that using the goto keyword (yes, I know).

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Jean, given this proposal it will be possible if the developer of the library intends so. You'll have to have unsealed classes to be able to subclass them and unsealed methods so you can override. It is possible to just allow subclassing without allowing overriding, just like final. As for

Re: [swift-evolution] [Pitch] Extending Swift Literals

I'm also not in for this. As mentioned before, these don't seem like literals but some sort of masking shortcut to other framework's calls to create the given objects. I think I could go only for colour literals here but if its literal representation were something close to HTML's. L On Monday,

Re: [swift-evolution] [Review] SE-0117: Default classes tobenon-subclassable publicly

Yes, app. Apps can be extended through plugins and you cannot write a plugin to an app without a library that exposes what you can do. That alone can expand my simple sample into a variety of examples: plugins. For the many types of folders I cannot enter details of my app now but check macOS'

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

You asked me to correct you and I shall: you're wrong. Although it seems like a filesystem representation here, this is not it and the subclassability of Entry and File is intended but Folder is a special type and I cannot allow more than the base type and a few controlled subclasses due to the

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

Should I assume then you want so much this proposal to be dropped you didn't even mind to look for the example so you wouldn't have to admit this proposal is needed? Fine, here is the whole of that example. I'm currently working on an app which will have object representations of Files and

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I've sent one I currently have myself. Look back on the thread posts. L On 8 July 2016 at 18:14, Tino Heth via swift-evolution wrote: > > When was the last time you you thought "I really wish the author of that > library had restricted my options to use it"? > > > I

Re: [swift-evolution] [Proposal] Variadics as Attribute

I meant only for the sake of variadics. That would "teach" the compiler to read "func x(args : Int...)" from our code and interpret it too as "func x(args ; [Int])" thus accepting lists of arguments or an array with the arguments with no additional effort from our part. L On 8 July 2016 at

Re: [swift-evolution] [Proposal] Variadics as Attribute

Kristof, this is the closest to what I've been proposing but I'm really unable to understand why it is to had to just change the compiler to recognise an array passed as argument to a variadic argument. No need for any extra keywords or complicated solutions, just make the compiler recognise that

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Just to relax a bit, from reading this thread I cannot help but feel a relation to Civil War. One can even say on which side everyone here would stand for real. #TeamIronMan L On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution wrote: > > > Sent from my iPad

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

+1. This would allow us to create observers on any foreign variable. I'm far from a compiler right now but I wouldn't this syntax create a new variable instead of observing an existing one? Even if not, by reading this one could be mislead to believe so. Perhaps you should give it something to

Re: [swift-evolution] [Proposal] Variadics as Attribute

It is definitely not hard to solve any issues here (if you consider only the basic variadics). Int... is nothing more than [Int], so essentially func doSomething(args : Int...) is also just func doSomething(args : [Int]) We just have to think of it like some form of function overloading

Re: [swift-evolution] [Proposal] Variadics as Attribute

I believe the alternative can be even simpler if you consider the type of the variadic argument is in fact an array. The different syntax tell the compiler it can relax on demanding an array for that argument and allow multiple comma-separated values of the same declared type. Nothing but the

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

making working with classes harder so be it :P. Seriously though Mine is the opinion of a library-maker, yours of the user of poorly designed/developed libraries. this kind of attitude on this list got to stop. Sent from my iPhone On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evo

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Jean, IMO marking every class as subclassable means the creator does not care for you to design and develop a great library because s/he is not caring for the library at all. I right now have to go through the burdensome activity of marking too many classes/methods as final to prevent misuse of my

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

I don't disagree with you on 'fileprivate' and 'private' being unnecessary and we may stick to the proposal at hand and leave the 'final' issue to another proposal, should anyone else care (I myself don't mind if it sticks around - just have to not use it). As for the conflict, I don't see it.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

So I did get what you meant right. Now tell me: if a class or method is internal to your module (and you know internal means only you, throught your source code, inside your app or library can extend it), do you really need to mark anything as final for any reason? Final on any non-publics is a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Scott, I think your writing got a bit confuse but, if I got your intention right, since you are the owner of the class, you may choose to subclass it or not internally, no questions asked. I need no finals in my apps and I only subclass if I intend to. If you are in control of your own code, why

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Scott, you really got a point here: should this proposal pass, I believe the final keyword should be removed as it would be already the default behaviour and thus unnecessary. I don't think this is on the proposal. L On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

to final/sealed helping you write better > libraries than having a final keyword for what you need to close instead? > > Sent from my iPhone > > On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution > <swift-evolution@swift.org> wrote: > >>> The

Re: [swift-evolution] Removing Variadic Parameters.

-1_000_000_000 I believe variadic parameters are useful in a range of situations and I use them myself a lot. As you mentioned yourself, you never created variadic functions and you are allowed to continue working like that for as long as it suits you so. It is a choice and you and other

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > > * What is your

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

And it is something the compiler can check whether it is necessary for your code or not based on some simple and easy pattern. If it is so simple, why not let the compiler handle it? On 4 July 2016 at 16:02, Vladimir.S via swift-evolution wrote: > On 04.07.2016 21:21,

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

My issue with this being opt-in is third-party libraries. The developer of a library may not have intended or thought of a use for the enum this way but some other developer might have. Being opt-in would prevent such scenarios from easily happening or require the developer to (again) manually

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

That is actually something I argued over this list with other users and (at least when I proposed) was not very well accepted. This certainly has my +1. On 4 July 2016 at 02:52, Gabriel Lanata via swift-evolution wrote: > I know! I am amazed this hasn’t had a formal

Re: [swift-evolution] [Proposal] Sealed classes by default

The proposal was to use "sealed" so why not "opened"? I understand it may not be common to use "opened" as an adjective but from the dictionaries I consulted it is possible to. opened class MyViewController: UIViewController { opened func displayMe(_ me: person) { … } } On 1 July 2016 at

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

I'll stick with Gwynne here. Each language has its syntax for interpolating string and as such I don't see a reason to change this. As for formatting, I agree it is an issue but we have to remember that inside \() we have code that can do pretty much everything one may need. You may even add a

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

On 21 June 2016 at 14:03, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The review of "SE-0101: Rename sizeof and related functions to comply with > API Guidelines" begins now and runs through June 27. The proposal is > available here: > >

[swift-evolution] the "guard" keyword, again

Perhaps that was the original idea (guard as a multithreaded statement) since in iOS your code and the UI run on different threads. Anyway, I'd still stick with guard as I don't think this is confusing enough to justify a change. On Tuesday, 21 June 2016, James Campbell via swift-evolution <

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need animpl

The thing with NSUnimplemented was really just a mention and nothing to do with the issue. As for the real issue, the blacklist you mention is formed after parsing the source. That's how compilers usually work. The function impl is expected due to the syntax definition that is checked during

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

I've seen around the Swift source code some uses of a function named something like NSUnimplemented(). I'm not sure this is available only inside the Swift source or if we could call it as well (I'm not in front of a Swift compiler right now so I cannot test). The idea of being able to drop the

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

I would vow to remove where clauses altogether. Most of the times I used it in ifs, fors and switches I ended up thinking it hardened readability of my code (perhaps because of placement, but I do not think alternatives made it more readable) and so it was my decision to stop using where

Re: [swift-evolution] Add conversion String -> Bool

I think it would be interesting if it could also recognise "1" and "yes" too as it can be useful in some cases. Perhaps have an option for this converter to be customised. L -Original Message- From: "Arsen Gasparyan via swift-evolution" Sent: ‎04/‎06/‎2016

Re: [swift-evolution] Working with enums by name

Patrick, I never said the order of the enum was intrinsic. If the offset of the case were the truth of the enum as you said enums would be ordinal types and you could do tests like "Planet.Mercury > Planet.Venus" without any extra code. But enums are nominal types not ordinal types so you can

Re: [swift-evolution] Working with enums by name

There are several ways to solve this, which IMO is a basic functionality of enums, writing code that is currently possible and works. But that's the issue, you still have to write code to have a basic functionally. I don't remember not being able to do this out-of-the-box in any language I

Re: [swift-evolution] Working with enums by name

I understand you don't like to rely on the name of your enum cases in you code and that's fine, you can still work with them as is, you won't have to change the way you work just because you don't like the proposal but that doesn't mean everybody has the same opinion you do. But perhaps then

Re: [swift-evolution] Working with enums by name

Brent, for needing "both Int and Double values" there is a proposal to add tuples instead of the current raw values or allowing assessor properties per case, you should check those out. Perhaps this could also be used to cryptoghaphically sign a raw value but I'm not sure. As for working with

Re: [swift-evolution] Working with enums by name

Enums outside frameworks will still rely on you as the programmer to know to which enum the string representation belongs to (it does so for the raw values) so I see no reason why the .caseName result should have the name of any underlying type the case belongs to. L On 1 June 2016 at 16:20,

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

I'm not much fond of Java enums but then Java also doesn't have structs so I think enums there were created to be a mix of structs and enums and that's why you can do all the things you mention on your list. That said: - The tuple typed enum approach is the closest thing we discussed to

Re: [swift-evolution] Ad hoc enums / options

Unions have been discussed earlier in this group and I personally think this is an issue better solved using function overloading. Despite this, I see how union types could be implemented (hint: Optionals) but to use it in code would require you to, at least, test for the type of the value at hand

Re: [swift-evolution] Working with enums by name

sva...@gmail.com> wrote: > Try this: > > enum Size: String { case Fit, Fill } > print(Size.Fit.rawValue) > > On 01.06.2016 13:42, Leonardo Pessoa via swift-evolution wrote: >> >> Just a fix. I've just tried the following code and the compiler complained

Re: [swift-evolution] Working with enums by name

Just a fix. I've just tried the following code and the compiler complained there is no .rawValue on the type. | enum Size { case Fit, Fill } | print(Size.Fit.rawValue) Then, as I said before, you can only get the value name as a string from interpolation and need to do everything by hand

Re: [swift-evolution] Working with enums by name

In this case of not using raw values in an enum, can you use init(rawValue:) as in my proposal? L -Original Message- From: "Charlie Monroe via swift-evolution" Sent: ‎01/‎06/‎2016 07:19 AM To: "Brent Royal-Gordon" Cc:

Re: [swift-evolution] Working with enums by name

Yes, you can do all this but you still have to do everything yourself by hand. Dictionary, plist, it even init as my initial example but you are the one responsible to control when e.g. you add a new value or rename another. My proposal causes no big changes and no big overload on the compiler;

Re: [swift-evolution] Working with enums by name

If I got the idea right, you would need to implement yourself the protocol methods to answer for both init(rawValue: Int) and init(rawValue: String) - which is how you have to do today only with the string part - while my proposed approach you'd have to implement nothing yourself. L > On 31

Re: [swift-evolution] Working with enums by name

Don't you think it's a bit of a waste to be repeating the name of the value as a string just to use init(rawValue:) with them? What if I need to store another string associated with the value of the enum e.g. I want to create an enum to represent options in a menu and the associated value is to

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I'd actually like to see a change in guard so that I don't need those braces. I'd like something more readable like | guard cond1 or return nil | guard cond2 or throw MyError.IllegalValue | guard cond3 or do { ... } It may add more cases for the compiler to handle but in all cases I used

[swift-evolution] Working with enums by name

Since we're talking a lot enums these days, I'd like to bring into discussion a proposal that has been briefly mentioned in another thread to enable working with enums using their names. This is currently possible in the language but it's a bit burdensome. You can just interpolate the value of

Re: [swift-evolution] Ad hoc enums / options

This is interesting. I don't think there is anything preventing these to be internally translated by the compiler as a true enums with random names (or any-other-way-we-shall-never-be-able-to-reference-again) thus adding the needed ObjC interop. L On 31 May 2016 at 13:24, Charlie Monroe via

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1 L On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution wrote: > >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution >> wrote: >> >> It isn’t a special case because all other single-statement closures in the >>

Re: [swift-evolution] [Pitch] #warning

In your alternatives considered, you mention "not all TODO or FIXME comments should surface" but I think the opposite: if I want these types of comments to be seen as warnings by the compiler I cannot choose which will surface and which not. It would be the same as saying "hey, but I don't want

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

Just complementing as I was on the run when I saw and responded the previous message. In my proposal, we would be allowing tuples to be used as if they were value types in enums. | enum Planet : (mass: Double, radius: Double) { | case Mercury = (mass: 3.303e+23, radius: 2.4397e6) |

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

Fréderic, the idea and reasoning are good and do make sense but I'm not 100% go on this. When I started using this syntax I felt like I was back in PHP but once I got used it's ok. I don't see anything wrong that justifies the change in syntax. Looking at your examples I even think it's easier to

Re: [swift-evolution] [Pitch] #warning

Tools like SonarQube can raise a "warning" for comments started with "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be presented as warnings instead of using #warning? And this could be an optional setting as commented would not influence compilation. -Original

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

I think that's the case with enums. You're changing their current behaviour of only having stored values to one in which it's computed (even if only once and then stored). Enums are IMO something that have a static value you know beforehand and can count on. That's why I'm not fond of the

Re: [swift-evolution] Variadic generics discussion

I hate C++ generics. Just thought about sharing this. > On 29 May 2016, at 9:00 am, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 1:22 AM, Austin Zheng wrote: >> >> Thank you for reading

Re: [swift-evolution] [Proposal] Protected Access Level

> attempting to write a Swift compiler in Swift today would probably result in > hard to read/reason about source code. Hmm, I still have to find some time to start working in this... ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Protected Access Level

You know the default access is was is used for this, right? And in this case I don't think they meant it for external subclasses to be able to access this change. I think this is how Swift was meant to work allowing only classes in a certain module to access such "private shared" parts and

Re: [swift-evolution] [Proposal] Protected Access Level

If we're to introduce the protected visibility, I think we should as well make it automatically internal or introduce an explicit protected internal visibility. I've been through many cases while programming in C# 'where' this was handy (thou I cannot name one from memory right now; it's been

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesfor each case

So it should either be an exception when using tuples (which I know is not good) or ensure the combination of values in all tuple values are different from one another. -Original Message- From: "Jānis Kiršteins" Sent: ‎28/‎05/‎2016 03:58 PM To: "Leonardo

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

My suggestion of allowing tuples as raw values instead doesn't burden the language and also does not eliminate rawValue (treat previously supported raw value types as one value tuples), reads very cleanly and supports a syntax we're already familiar with. I don't see how the 'where' syntax

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

I agree. These are different proposals that can coexist but I think they should be evaluated separately by the community. -Original Message- From: "Vladimir.S via swift-evolution" Sent: ‎27/‎05/‎2016 08:05 AM To: "Charles Srstka"

Re: [swift-evolution] [Pitch] Property reflection

I'm also not fond of allowing what could be called a backdoor to accessing privates and intervals too but has anyone thought of enhancing the Mirror class instead of having something totally new? I've tried using it once but in the end it wasn't necessary for what I needed to do. An opt-in

Re: [swift-evolution] [Proposal] Enums with staticstoredpropertiesforeach case

Ok, I'm not familiar with Scala but if the language does not have support for the type of enums we're discussing it may be their chosen mechanism to handle enums with associated values (feel free to correct me if I'm wrong always) but my main point for enums is still: do we really need to

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

sNetworkError: >> false, isIOError: >> true) >> ... >> >> } >> >> So that you assign the additional information to the enum >> value itself. >&g

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

y 25, 2016, at 10:27 PM, Jacob > Bandes-Storch <jtban...@gmail.com > <mailto:jtban...@gmail.com> > <mailto:jtban...@gmail.com >

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

t; } > > So that you assign the additional information to the enum value itself. > > Charlie > > > > On 26 May 2016, at 1:47 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > > On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch &

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

I'd still go with tuple syntax as it feels more like a natural extension to current enum syntax and does not introduce new elements to the syntax of enums (other than add tuples as a possible enum value type) thus being simpler and faster to implement and learn than a new syntax built

Re: [swift-evolution] [Pitch] Remove associated type inference

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

I get it that the point here is about the intention. If you mean to call that initialiser, using an extra name or none should make no difference. If there is a chance people are misusing the nameless initialiser, I don't see a reason why not adding a name here. On Wednesday, 25 May 2016, Karl

Re: [swift-evolution] [Pitch] Remove associated type inference

On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, May 25, 2016 at 2:52 PM, David Hart > wrote: > > > >> On 25 May 2016, at 23:47, Dmitri Gribenko > wrote: > >> > >>

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

But that's an issue related to how serialising JSON works. Should the API serialise the name of the value and not the associated values, it should work fine. Should we have anything like annotations in Swift to describe how we wanted that output we'd have no problems. About breaking things I

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

I like the idea of sealed types but I think much better is Ceylon's concept of previously declaring the many subclasses that are going to exist both because I can have a bunch of public classes in a framework and restrict their subclasses and because there are threads in this group discussing

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

Limiting the amount of subclasses is not really a good idea as you would need to introduce another mechanism in the language while the proposed feature requires much less. And you're thinking only about the restrictive set (internal and private) and forgetting the more open end (public). Why is

Re: [swift-evolution] [Discussion] Namespaces

Adrian, I myself don't see a reason other than "Objective-C never had it so why bother about it now?" Most (if not all) .net languages support optional namespaces and even PHP began supporting it in version 5 (if I'm not sure if the version is right). No technical reason against and I'm

Re: [swift-evolution] RFC: didset and willset

Matthew's right. The first thing here is to define a consistent rule which takes no exceptions and then apply this rule to every existing or new keyword and attribute. On 18 May 2016 at 18:02, Matthew Johnson wrote: > >> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> Hello Swift community, > > The review of "SE-0091: Improving operator requirements in protocols" begins > now and runs through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > >

Re: [swift-evolution] RFC: didset and willset

I may be wrong but I don't remember any other case of a keyword in Swift composed of two or more words, so I believe these should be exceptions. I would agree best to change these keywords for others consisting of only one word but I myself have no suggestion what those could be. Otherwise I'd

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > * What is your

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> Hello Swift community, > > The review of "SE-0089: Renaming String.init(_: T)" begins now and runs > through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md > > * What is your

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

> The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May > 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md > > * What is your evaluation of the proposal? I have nothing against

Re: [swift-evolution] [Pitch] Requiring special keyword to mark protocol implementation methods

Hi Vladmir! There is something very similar to this in C#. I like this but I'd like to enhance it a little bit. I don't think it's necessary to decorate protocol methods any further but some warnings by the compiler would be welcome, like when pushing a type to adopt a protocol through an

Re: [swift-evolution] Proposal: Finalization in protocol extensions and default implementations

Adrian, what would be the meaning of this final declaration? In my understanding, a final means there can be no more overrides of that method but there are no implementations in a protocol so I really don't understand this use. On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution

  1   2   >