Re: [swift-evolution] Pitch: @required attribute for closures

> Am 05.06.2016 um 11:37 schrieb Charles Srstka via swift-evolution > : > > MOTIVATION: > > As per the current situation, there is a pitfall when writing asynchronous > APIs that does not occur when writing synchronous APIs. Consider the > following synchronous

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:56 schrieb Xiaodi Wu via swift-evolution > : > > My response was simply to say that Never or NoReturn would in fact be a type, > which is a good justification for looking like one. This behavior would be > learnable and is theoretically sound,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution > : > >> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> I disagree. We are discussing how to annotate a function in some way so >>>

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution > <swift-evolution@swift.org>: > > >> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> Am 07

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:36 schrieb Charles Srstka via swift-evolution > <swift-evolution@swift.org>: > >> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolutio

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Ok, one last thing, then I go to sleep for today... Basic Definition of a "Type": I learned in university that a type is a "set of values". When a function has a return type of R, it means that it does return a value of type R. On the other hand, a @noreturn function doesn't return any value,

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Hi, you may think of `defer` as a function that pushes a block onto an implicit cleanup stack that is part of every lexical closure. On each scope exit, all blocks from its cleanup stack are popped and executed. E.g.: func f(x: Int) { defer { print("A"); } defer { print("B"); } if

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 06.06.2016 um 00:53 schrieb Charles Srstka <cocoa...@charlessoft.com>: > >> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via sw

Re: [swift-evolution] Pitch: @required attribute for closures

> Am 06.06.2016 um 22:30 schrieb Charles Srstka via swift-evolution > : > > On Jun 6, 2016, at 2:49 PM, Michael Peternell > wrote: >> >> That's really hard to answer in the general case. I think real proposals >> should contain concrete,

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Hi, I think that's an awful idea. I can already tell you that this will never be accepted. It just complicates the design and the semantics of the `defer` statement, and I don't see any advantage. Sorry. -Michael > Am 06.06.2016 um 22:14 schrieb donny wals via swift-evolution >

Re: [swift-evolution] [Review] SE-0096: Converting dynamicType from a property to an operator

Isn't `dynamictype` different from `sizeof` or `typeof` in that it does evaluate it's argument? I think it's safe to write `typeof(system("rm -rf *"))` *, because `typeof` will return the static type of the expression, without evaluating it. `sizeof(44*x)` will not perform a multiplication,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution > : > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would like to call the type

Re: [swift-evolution] Pitch: @required attribute for closures

> Am 05.06.2016 um 20:31 schrieb Charlie Monroe via swift-evolution > : > > While I agree with Michael that nowadays, a lot of stuff that doesn't need to > be, is done async, which leads to a giant thread pool per app and developers > nowadays do not think of the

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that automatic conformance can be defined in the language itself and that derived protocol instances don't have to be implemented as compiler intrinsics. That's just not the case. You cannot define something like @auto

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> Am 26.05.2016 um 17:35 schrieb Matthew Johnson : > > >> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution >> wrote: >> >> +1 to a `deriving` keyword > > + 1. I like it as well. It makes the feature opt-in, declaring

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Can we just copy the solution from Haskell instead of creating our own? It's just better in every aspect. Deriving `Equatable` and `Hashable` would become struct Polygon deriving Equatable, Hashable { ... } This has several advantages: - you don't have to guess wether `Equatable` or

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

Something similar to #error seems to be already implemented ;) #if os(iOS) import Error_sorryThisDoesntWorkOnIOSyet #endif I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, #error would look nicer) -Michael > Am

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

It seems that there are two groups here. 1) Group 1 wants Equatable (and others) be derived automatically unless specifically overridden: similar to auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants Equatable (and others) be derived explicitly using a `deriving`

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

> Am 22.06.2016 um 02:11 schrieb Dave Abrahams via swift-evolution > : > > > on Tue Jun 21 2016, Brandon Knope wrote: > >> Maybe this is flawed, but I think it is hard to argue that the \ is >> easy to type when there are far more usable

Re: [swift-evolution] Compiler Warning on Unextended Classes

I think unextended classes shouldn't be a compiler warning. They even shouldn't be an optional linter warning. There is a class. It doesn't have subclasses because I may have not written them yet. The process of writing software has to be anticipated somehow. I have 2 options: 1) I write the

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

I've used something that is very similar to dispatch_once in Swift 2.2. It looks like this (taken from real code in a real application): public static let defaultMap: RAStaticMap = RAStaticMap.loadCountries() The function RAStaticMap.loadCountries() is actually private, and it is called

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> Am 21.06.2016 um 19:03 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available > here: >

Re: [swift-evolution] [Pitch] String prefix operator

> Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution > : > > Motivational example: > > var urlString = self.urlString > if urlString.hasPrefix("//") { > urlString = "http:" + urlString // urlString needs to be typed twice > } > > While there is

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

I'm not sure if this even requires a proposal. This just looks like an ordinary bug in the language implementation. But if this would become a formal proposal, I will support it. -Michael > Am 23.06.2016 um 21:53 schrieb Slava Pestov via swift-evolution > : > >

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

2016 um 08:32 schrieb Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org>: > > >> Le 27 juin 2016 à 00:00, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >>> >>> Am 26.06.2016 um 23:03 schrieb

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

Just one question: If I have functions json_encode(j: JSON) -> String and json_decode(j: String) -> JSON throws what should be the type of JSON? What should '{"a":2,"b":null}' decode to? What should the type of the JSON null value be in Swift? I think String and String? and String??? are wrong

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

> Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org>: > > Optional are definitely the best way to represent null when parsing JSON. > >> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution >> &l

[swift-evolution] [Proposal] Threadsafe lazy vars

Hi all, lazy vars are not threadsafe in Swift 2. I saw code that uses lazy initialization in an unsafe way that introduces race conditions so often that I would be rich by now if get a penny each time. Many people use patterns like { if(_var == nil) { _var = [self _calculateVar]; } return

Re: [swift-evolution] Proposal: disallow nil in favor of .None

Please not!! If this was an April 1 joke, it's too late. Von: Paul Young Betreff: [swift-evolution] Proposal: disallow nil in favor of .None Datum: 10. April 2016 22:53:18 MESZ An: "swift-evolution@swift.org" Please forgive me if this

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

Is "Self" dynamically dispatched? What would the following program print? class A: NSObject { static func myClassName() -> String { return "A" } func hello() -> String { return "I am a \(Self.myClassName())" } } class B: A { static func myClassName() -> String

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

+1 I think it's a good thing. I don't think that it would introduce any bad ambiguities for the human reader. E.g. "case .default:" may look like "default:", but so does "case .`default`:" - all other cases that I can think of don't seem to introduce any problems. > Am 26.04.2016 um 06:20

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> • What is your evaluation of the proposal? -10 strongly against it. I can't see that it would create any ambiguities to not use parens. In all cases, I can see the meaning of a function type, e.g. Int -> String is a function that takes an Int and produces a String; (Int) -> String

Re: [swift-evolution] multi-line string literals.

It really amazes me what some people think multiline strings are. For me, the *definition* of a multiline string is this: """A multiline string allows you to copy most text, without having to use any special string quoting rules: that's the primary use case. For example, you can embed

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Isn't there a strong convention that overloaded methods should be very similar? Like a print function that takes a String and a print function that takes an Int? Having two 'sort' functions that are not even similar, but that just refer to the same concept ('sorting') seems confusing, and I

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

In my opinion, requiring something is almost never something that I would describe as a "feature". I don't really care if the keyword is called "optional" or "objcoptional", I think both are fine, but I wouldn't want it to read "@objc optional". The "@objc" in "@objc optional" should be

Re: [swift-evolution] Guaranteed closure execution

Hi, > Am 23.04.2016 um 14:56 schrieb Gwendal Roué via swift-evolution > : > > Thanks for your input Michael, > > You're right that argument modifiers should go before the argument, and type > qualifiers before the type: > > func f(@once closure: @noescape ()

Re: [swift-evolution] Guaranteed closure execution

Hi Gwendal, > Am 23.04.2016 um 12:18 schrieb Gwendal Roué via swift-evolution > : > > Hello Andrew, > > I'm rather embarrassed: the initial design of this proposal was based on a > modifier of @noescape: > > func f(@noescape(once) closure: () -> ()) { … } >

Re: [swift-evolution] multi-line string literals.

Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :) let x = XMLDocument(<

[swift-evolution] multi-line string literals proposal

I've written up a proposal for multi-line string literals. Before proposing it officially, I would like to get some informal feedback. How can I propose it officially? Do I have to convert it to Markdown? I have no idea how to create a Markdown version of this, with all the quotes and funny

Re: [swift-evolution] multi-line string literals.

is it just me who would prefer a multiline string literal to not require a \backslash before each "double quote"? Did you ever really use multiline string literals before? I did, and it's mostly for quick hacks where I wrote a script or tried something out quickly. And maybe I needed to put an

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

I think that would be a good feature. > Am 28.04.2016 um 19:15 schrieb Brad Hilton via swift-evolution > : > > Type nesting allows some convenient and straightforward semantics that we see > inside the Swift standard library such as views on String like >

Re: [swift-evolution] multi-line string literals.

"""Just in my opinion: having to start each line with a particular token kinda defeats the purpose of multiline string literals. "can't we just continue" "the literal on the next line anyways," "like in C?" "or maybe the "+ "at the end of the line can be"+ "optimized away?" """ What is wrong

Re: [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()

Comments inline > > https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md > > * What is your evaluation of the proposal? A big +1 from me. It doesn't create any incompatibilities. Old code will behave the same as before. autoreleasepool

[swift-evolution] [idea] Make functions with @noescape syntax behave like control structures

I have an idea that touches the Swift compiler, Xcode and the debugger. I'm not sure if any language support is needed for this feature, or if it is just a debugging issue, or just an Xcode issue. THE PROBLEM What often irritates me with closure literals, is that you cannot easily step into

Re: [swift-evolution] Static Dispatch Pitfalls

> Am 20.05.2016 um 21:51 schrieb Fabian Ehrentraud via swift-evolution > : > >>> Sorry, I understand and appreciate your pragmatism. Right now it feels >>> very much like a fight to the ideological death between POP and OOP >>> and it may get really bad results this

Re: [swift-evolution] Pitch: Modify the meaning of IBOutlet to remove the ! from the type

The really nice thing about the "!" operator is that it is always explicit. Either in the variable declaration, or when unwrapping it with "!" or "if let". "@IBOutlet weak var"s should therefore really not introduce an implicit "!". It's just one character, and it's good to see that this is

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Well, I wouldn't deprecate them. Maybe it should print something different: the value itself if it is not nil, and "nil" otherwise? Or there may be an optional warning for this case. Or maybe both. But not just deprecate the feature altogether. It will make people use the "!" instead in

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

Hi Erica, "didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the

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

> Am 18.05.2016 um 22:58 schrieb Josh Parmenter via swift-evolution > : > > I have a general preference for camelCase as well, but I would prefer > consistency in the language over my own personal preference. In fact, I wouldn't care much about the naming. But I

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> Am 18.05.2016 um 21:53 schrieb Goffredo Marocchi via swift-evolution > : > > The code you pasted really ought to print a warning out (allowing variable > shadowing without even a warning can lead to annoying bugs), a generation of > Swift developers will be

Re: [swift-evolution] Support for coding styles and "swift-format" tool

What I would like even more is editor support with this stuff. And I think the "swift-format" tool could probably help here too. I remember a time when we had problems with LF vs. CR vs. CRLF line endings. How did Sublime Text Edit (or any other sane editor) solve this issue? Do we all have to

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Well, SE-0009 is not related to shadowing, is it? I think it is something completely different. The problem that SE-0009 tries to solve is that when looking at a line in isolation, like print(foo) there is no way to tell wether foo is an iVar, a local var or a parameter. This can happen

[swift-evolution] Swift 3 and cross platform development

Hi, I've seen on the swift-evolution git repository README.md page that Portability is one of the design goals for Swift 3. Does this mean that Swift 3 will be available and useful on Windows too? So that it could be used for cross platform app development on both Windows and OS X (and

Re: [swift-evolution] Idea: Named extensions

Why not just use a (documentation) comment? /// The Lifecycle extension: extension ViewController { ... -Michael > Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution > : > > I like to separate methods into their own logical extensions so similar >

Re: [swift-evolution] Union instead of Optional

> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution > : > > Precisely. To me unions are to enums with associated type the same way tuples > are to structs. One is named, has well-defined semantics, can conform to > protocols, can have complex internal

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> Am 14.05.2016 um 09:31 schrieb Charles Srstka via swift-evolution > : > > I don’t think Cocoa is going away for a very, very long time. Even if it did, > you’d still need some consistent way to turn an ErrorType into something > human-readable, and currently we

Re: [swift-evolution] Auto Unwrapping Of Optionals

I thought about this too, and I think it would be convenient. It feels a bit like artificial intelligence though, and I'm not sure how easy it would be to implement this. It should be sharply defined what the compiler should infer and what not. This can be very hard. For example, you write

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

> Am 06.05.2016 um 14:08 schrieb Marc Prud'hommeaux : > > >> I wonder if there is a practical use-case for this.. Is there? Just >> curious... > > Without getting too deep into the weeds of our specific data modal, I'll > summarize with "yes". If you need to mix classes with

[swift-evolution] [Proposal] Multiline string literals

Hi, I propose adding multiline string literals to Swift 3. I have written up a proposal as a Github Gist, here: https://gist.github.com/michaelpeternell/a4da4185de78808f4575a836c50debbd Can someone with write-access

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

comments below. > Am 28.04.2016 um 20:12 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0052: Change IteratorType post-nil guarantee" begins now > and runs through May 3. The proposal is available here: > > >

Re: [swift-evolution] [Idea] Remove optional pattern binding

I totally agree with you. I think there are many things that are really well-designed in Swift 2 currently, and most things should stay the way they are. I felt that it is really easy to learn (compared to other languages like, e.g. Perl or Haskell at least) and that the code usually works as

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Furthermore, YES/NO in Objective-C is not the same as true/false in Swift: I'm always watching out for code that checks if a BOOL value is YES, because YES just isn't the only true value in Objective C. The following code has a subtle bug in Objective-C whereas it works nicely in Swift. (One

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

Hi, just a quick question... would it maybe be feasible or practical to have "sub-OSes", like e.g. `#if os(Windows.MSVC)`, `#if os(Windows.Cygwin)` or `#if os(Windows.MinGW)`? -Michael > Am 03.05.2016 um 20:43 schrieb Jordan Rose via swift-evolution > : > > We’ve

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

I wonder if there is a practical use-case for this.. Is there? Just curious... -Michael > Am 03.05.2016 um 17:07 schrieb Marc Prud'hommeaux via swift-evolution > : > > > The following code currently has a retain cycle and memory leak: > > enum ParentChild { >

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

comments inline > Am 04.05.2016 um 05:52 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0060: Enforcing order of defaulted parameters" begins now > and runs through May 9. The proposal is available here: > > >

Re: [swift-evolution] multi-line string literals.

Hi, it's not a secret that I'm not a big fan of the proposal. The third draft doesn't change this and it's unlikely that any future draft will, because for me, the problem are the continuation quotes, and for Brent it seems like they are a must-have-feature (correct me if I'm wrong.) I just

Re: [swift-evolution] multi-line string literals.

> Am 06.05.2016 um 05:24 schrieb Ricardo Parada : > > I think that is another one of the advantages of using the continuation > quotes. > > Sent from my iPhone > >> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution >> wrote: >>

[swift-evolution] Question about SE-0057 "Importing Objective-C Lightweight Generics"

https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md How can Swift know if an Objective-C class implements +/- classForGenericArgumentAtIndex: at compile time? Does it look at the object code? Or does it look at the header file? Or maybe there is a

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

I don't see any advantage of requiring parenthesis. I think programmers should be allowed to write (Int) -> Int, and they should also be allowed to write Int -> Int. -Michael ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

@Radek: I totally agree, and would like to add some more reasons. (For me), (parenthesis are mostly (a tool) to disambiguate the (parse tree)). a parenthesis around (just (one token)) doesn't really make sense, or disambiguate anything, IMHO. They tell the parser, "you think I meant 'a+(b^2)'

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Regarding the original proposal: I like the idea. I think it would be nice to allow the application of variadic args from an array. The syntax I could think of is: let args = ["World"] printf("Hello %s", *args) So, "*" just converts "[a,b,c]" into "a,b,c", that's the idea. What do you think?

Re: [swift-evolution] What about a VBA style with Statement?

I think the idea is good, but I think it would be bad for the language overall. -1 As a plus, it makes code easier to write, sometimes; or at least it seems so. On the other hand, I think it makes code harder to comprehend. A `with` statement introduces a new scope in which it is not obvious

Re: [swift-evolution] multi-line string literals.

Comments inline. > Am 26.04.2016 um 15:32 schrieb Ted F.A. van Gaalen : > > Hi Michael > > What happens if a delimiter in this case: “”” > occurs embedded in the data? like so (two times here): that's a problem you always have. And I think pasting a few lines of text

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

> Am 21.07.2016 um 14:48 schrieb Tino Heth via swift-evolution > : > > >> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution >> : >> >> Oops missed sending to the list. > it's quite easy to hit the wrong button — but

Re: [swift-evolution] Swift 3.1 discussions, go?

Haha ;) 1) Maybe converting the algorithm into a tail-recursive form should be the first optimization? func factorial(_ n: Int, multipliedBy m: Int = 1) -> Int { return n <= 1 ? m : factorial(n-1, multipliedBy: m*n) } 2) Using a non-recursive algorithm would improve performance even more,

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

+1 this should be a bugfix. > Am 18.07.2016 um 19:36 schrieb Chris Denter via swift-evolution > : > > Hello – > > Currently, the standard library String functions .hasPrefix() and > .hasSuffix() will return false when given the empty string as input: > > $ swift >

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

> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution > : > > Sealed methods can be overriden inside the defined module/library but > not outside. Same benefit of classes. Interesting how the supporters of the proposal seem to imply that the opponents

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

Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in the Swift core team is strong enough so that I cannot believe that this has a chance of ever being implemented at all :) Why do I think it's terrible? I do subclass classes even when they say that you shouldn't do it.

Re: [swift-evolution] Setter methods for vars

So you're proposing that `#set(aVariableName)` should translate to `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue like `self.users` or `users` or `vc.viewControllers`.. I think this would be a good extension to Swift. (`users.set` does not work BTW, because maybe the

Re: [swift-evolution] Setter methods for vars

up with a bigger design that ties to reflexion. > >> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> So you're proposing that `#set(aVariableName)` should translate to >> `{aVariableName=$0

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

> Am 29.06.2016 um 00:32 schrieb John McCall : > > The decision to make class methods polymorphic by default was always premised > on being able to undo that in obvious cases where methods are never > overridden. Making a class public so that clients can use it shouldn't

Re: [swift-evolution] Setter methods for vars

nk largely Haskell > in particular?). I don't know much about it, but here's somewhere to start: > https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf > > l8r > Sean > > Sent from my iPad > > On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution >

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

> Am 06.07.2016 um 01:11 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

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

IMHO SE-0117 is one of the worst Swift 3 proposals that have ever been proposed. It has the potential to make the language much worse. I haven't seen any problems at all that are caused by people trying to subclass classes that they shouldn't, so I'm wondering where this fear of bad subclass

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> Am 29.06.2016 um 23:57 schrieb Xiaodi Wu via swift-evolution > : > > On Wed, Jun 29, 2016 at 4:46 PM, Matthew Johnson > wrote: > >> On Jun 29, 2016, at 4:19 PM, Xiaodi Wu wrote: >> >> On Wed, Jun 29, 2016 at 4:16 PM,

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> Am 30.06.2016 um 00:17 schrieb Xiaodi Wu via swift-evolution > : > > Here is the problem: > > ``` > private struct Foo { > /* private */ struct Bar { > // it doesn't matter what you write in here, you'll never see it in `Foo` > } > } > ``` > So this is

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Hi, Maybe I'm wrong but as I understood the semantics of the visibility modifiers as this: 1) each declaration X has a certain scope S 2) sub-declarations of X have the same scope S unless the scope is explicitly stated with a keyword (but rule #8 (about `public` access) is stronger.) 3) a

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

Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really make sense. `internal` declarations are always sealed. -Michael > Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution > : > > Do we really need a new keyword? Since we already have

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

> Am 29.06.2016 um 08:33 schrieb Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org>: > > >> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> >>> Am 29

Re: [swift-evolution] [Proposal draft] NSError bridging

Hmm, not all NSErrors are Cocoa Errors. CustomNSError is a perfectly scoped name: CustomError would be too vague, CustomCocoaError excludes errors thrown by AVFoundation. And the intent is perfectly clear without explanation. I think a CustomCocoaError would have documentation comment that says

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

> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution > : > > +1 for the concept of a "sealed” class. > -1 for making it default. Aren't sealed classes already implemented? I think the keyword is `final`.. So there is nothing left to do :)