Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> It is an instructive example of why remaining with a mailing list, flaws and > all, is probably the best answer for Swift Evolution. I don't get this: If Swift Evolution had been using something more versatile than mailing lists, there wouldn't have been the need to use Gmane, which just

Re: [swift-evolution] [Idea] Generic subscripts

> Since RangeExpression is a protocol compatible with any index type, it has to > have an associated type I haven't read all linked information, but would the situation change with generic protocols? Thinks like "AnyGenerator" afaics would be superfluous if we had "protocol Generator", and the

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

> to make use of Swift more appealing and useful for science, engineering and > finance and everything else involving actually calculating things, I think it > would be a big step forward if Swift would ship with its own math/numerics > library. There are several topics that imho would benefit

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> Am 15.08.2016 um 09:02 schrieb Justin Jia via swift-evolution > : > > foo.bar(x: x?) Yes, those guards and ifs can be tedious, but it is clear what they are doing, and there is no doubt what code will be evaluated and what will be skipped. If Swift had syntactic

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

> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution > : > > If you can’t trust a developer, how could you use its library ? I guess you're getting this wrong, and maybe on purpose: Thrusting a developer is competent and tries to do a good job is on

Re: [swift-evolution] An Alternative for Extensibility Modifiers

Imho overall this is a good proposal, yet it saddens me to read this thread, because it's a good proof for the dogmatism I mentioned before: You address all issues of proposal 0117 in a more consistent way with less confusing keywords, even adding some features that are actually handy — but yet

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

> Publishing a library is a promise of something. It ought to only be promises > the library author wants to make. If “the truth” is “the implementation in > the current version of the library”, that’s definitely not what a library > author should promise. That’s true for plenty of things, not

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

> Am 20.07.2016 um 18:20 schrieb L. Mihalkovic : > >> So my advice: Be glad that you don't see such problems in your real work >> life, and hope that the extremists who would like to completely remove >> classic object orientation and cripple Swift to fully match

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

> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution > : > > A class that is closed in 1.0 can be opened in 1.1; a class that is `final` > in 1.0 *cannot* be opened in 1.1 (or at least it's a breaking change if it > is). Wait a moment: Aren't

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

> Am 20.07.2016 um 21:54 schrieb Chris Lattner : > > I’m sorry I’m late to this thread, but I’m personally strongly opposed to > this. May I ask a general question: What implications does this statement have? Is it "spare yourself from unnecessary work, this will never be

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

> 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 actually, the first recipient list was a better fit for the spirit of your motivation ;-) > Swift 3 is going to

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

I naturally assumed that "public" and "open" would be two separate concepts, as it has been expressed that orthogonality* is favored. But actually reading the proposal, it says: "open is invalid on declarations that are not also public", which imho not only is an unnecessary mingling of the two

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

I naturally assumed that "public" and "open" would be two separate concepts, as it has been expressed that orthogonality* is favored. But actually reading the proposal, it says: "open is invalid on declarations that are not also public", which imho not only is an unnecessary mingling of the two

Re: [swift-evolution] [Pitch] Set of AnyObject by reference

> What I hope to achieve is to have a Set of unique objects by their > references. For example, I might put in two rectangles with the same height > and width (which makes them equal, but they are still different instances). I guess this is not the best place for such problems, but did you

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

> Am 19.07.2016 um 04:11 schrieb Jonathan Hull via swift-evolution > >: > > Second, I would really like to see the methods match the open-ness or > final-ity of their enclosing scope by default. Note: I also feel this way > about

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

> Am 19.07.2016 um 09:43 schrieb Brent Royal-Gordon via swift-evolution > : > > We need to be bold and take a chance. If it doesn't work out, we can undo it. > But if it does work out, we'll be better for it. It's hard for me to associate a proposal that is grounded

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

> Am 17.07.2016 um 18:31 schrieb Haravikk : > > I may move discussion of other collection types to its own section though, to > make the core proposal as simple as possible, and leave it up to the core > team whether to do that part. imho this is a good idea: Its

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

Hi Peter, > Am 20.07.2016 um 00:26 schrieb Peter Livesey via swift-evolution > : > > 1. I don't understand what problem this solves? That's just natural — most likely you have just a different mindset. There are already several cases where "bureaucrats try to

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Hello Johannes, > Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution > : > > 1. Custom implementation of equals operator `==` for value types should be > forbidden. Rationale: Why has it been added in the first place? For omitting > some values

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

> does it make sense to require every member to be marked as “overridable” in > order to be overridden by an open subclass outside of the current module? Despite of probably being one of the most passionate defenders against adding restrictions on subclassing, I've to accept the clear

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

The last post in this thread is nearly a week ago... did you already apply for review? It would be a pity if this topic isn't finished, and I think a reduced variant that merely replaces "values: Int…" with "@variadic _ values: [Int]" shouldn't be a problem for Swift 3, leaving the possibility

Re: [swift-evolution] Public classes with private superclass

> How would this look in the exported API? Would it simply show itself as not > inheriting from anything? If your base class inherited from something (e.g. > NSObject), would the public subclasses show themselves as direct subclasses > of that superclass (NSObject)? I wouldn't care, but the

Re: [swift-evolution] Public classes with private superclass

Thanks for the link — imho it's really hard to keep an overview of this list… So, I'll follow the leader ;-) and delay further posts on this topic >> Not everything can be solved with protocols (stored properties, anyone?) > > Sure, it's not completely painless, but you can declare > >

Re: [swift-evolution] Removing Variadic Parameters.

> The second case would looks really strange without the variadic parameter > (calling site) syntax and it would no longer look like it’s one continuous > list of values. agreed, that would be odd — but I really hope that there will be a nice alternative in the future. One very fundamental

Re: [swift-evolution] Removing Variadic Parameters.

> Objective-C has variadic messages. I'd be surprised if any seasoned my fault — how could I forget those nil-terminated array-initializers? ;-) Yes, Objective-C had variadics, but imho they have been much worse than in Swift. ___ swift-evolution

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

> Am 07.07.2016 um 02:27 schrieb Jonathan Hull via swift-evolution > : > > 1) This method MUST be overridden > 2) This method should NOT be overridden > 3) This method MUST be called > 3) This method should NOT be called except by subclasses >

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

There are (were?) plans for generalized property behaviors; those would be used to implement lazy, as well as didSet/willSet, and could incorporate many other things (including injection) Of course, an option to observe variables would be handy — but there's always a price to pay, and you'll

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

> 1. As you point out, the majority of the surface area of idiomatic Swift APIs > are unlikely to be impacted (value types, protocols, and final classes). > This is very likely to apply to future Swift-native APIs from Apple > regardless of the outcome of this proposal. > > 2. There is no

Re: [swift-evolution] Removing Variadic Parameters.

It's a late answer… but I wanted to be a good citizen and checked if the topic has been discussed before; so, it seems that is not the case ;-) In short, I agree: Variadic parameters are somewhat cool, and I think I was exited when I've seen them in C the first time… but I afair, I never

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

> If you have a ParentClass and a SubClass, and the ParentClass is sealed while > the SubClass is subclassable. What happens? No matter how this question is > answered, I don't like the answer. (compile error => bad. || make it as the > user wishes => bad; what do we gain by letting

Re: [swift-evolution] Removing Variadic Parameters.

> I believe variadic parameters are useful in a range of situations and > I use them myself a lot. Can you talk about concrete examples? Because Objective-C had no variadic messages, it's natural that the feature isn't utilized in Cocoa, but I doubt that it is used by many native Swift

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

-1, against all odds. I can't fight the feeling that many fans of ideas like this believe that good designed libraries come for free by simply adding restrictions — which, at least in my opinion, just isn't true: No matter what the defaults are, good libraries are hard to build, so I predict

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

>> When was the last time you you thought "I really wish the author of that >> library had restricted my options to use it"? > > I really wish Objective-C had this feature from the start. I believe there > would have been significant benefits to Apple's platforms and ecosystem. The >

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

> Yes, I know it'd all be the epitome of annoying boilerplate code, but my > point is that if someone wants to subclass something of yours, there's really > not much you can do to stop them. This would be fine: inheritance bad, composition good ;-) The problems of this attitude just aren't

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

> Forking is desirable if your goals, needs, values, etc are substantially > different than the library author such that you do not agree on what the API > contract should look like. That's desirable in the same sense as an amputation that saves you from a deadly sepsis... I'd rather stay away

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

> Of course it can be done either way. But there are significant ecosystem > robustness advantages to making sealed the default and comparatively few > downsides. Most libraries are open source (so can be modified directly or > via PR if necessary) First: The claim about robustness sounds

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

> Also "subclassable class" sounds a bit redundant. In other words, I think > subclassable implies it is a class. That's a good point: There is no inherent reason that you can't inherit from a struct, and that might be possible in a future version of swift. "subclassable struct MyValue" doesn't

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

> The problem with this is simple: you cannot retroactively "close up" an API. > I cannot add final to a class I have previously declared as non-final. I also > can seal a class which has previously been open to subclassing. Of course you can do both — it may make users angry, but so what? The

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

> You asked me to correct you and I shall: Well, in the first place, I asked how many subclasses you have to "seal" manually… may I assume that it is a low number? > You asked for an example where this feature would be needed and I've provided. No, actually you provided an example where you

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

> It is *not* the case with a framework. Dynamically linked frameworks can be > changed without the app even being changed. Imagine if Apple changed UIKit > and make UINavigationController final retroactively. Your argument is true, and you choose a good example — but it's actually the only

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

> Am 11.07.2016 um 03:45 schrieb Rod Brown : > > That said, I actually think you have a good point however that “sealed” > should be able to be overridden, either in a patch capacity or an “unsafe” > capacity. Should this become final at a later point, you have

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

> In the implementation of the subclass, there has to be a call to one of the > superclass's initializers. If all of the superclass’s initializers are > non-public, then there’s no way to write your own initializer. (This is > actually true in Swift today.) I want to point out that this

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

> With the existence of Swift on the server, dynamically linked, independently > distributed frameworks will not be an Apple-only issue - this extends beyond > Apple's OS X-based platforms towards how dynamic frameworks link against each > other as if they are to be distributed separately. >

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. This list has thousands of messages, this topic alone is split into at least six

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

Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to

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

> The justification for this proposal is all about supporting the people who > are working to design library APIs right, and about maintaining consistency > with the design philosophy of Swift. To wit: in Swift, where there’s a > default choice, it’s the safe one; I challenge this claim:

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

> You do realize that then itunes store used to (i don't know hese days) for > many years run on java, despite objc being such a more advanced environment. > ;-) well, from my experience, app developers are running circles around the itunes store all the time ;-)

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

I haven't read the whole Library Evolution document, but one important part is written right at the top: > This model is largely not of interest to libraries that are bundled with > their clients (distribution via source, static library, or embedded/sandboxed > dynamic library, as used by the

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

> Here, I also disagree. Imagine we are talking about an open-source library on > GitHub. People will complain about the lack of sub-classability through > issues and pull-requests. This will hopefully be enough to get discussions > going on what is wrong with the API to warrant subclassing

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

> In an open source world, “closed by default” makes a lot more sense. That sounds Orwellian to me: War is Peace, Freedom is Slavery, Ignorance is Strength — and sealed is open?___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Discussion] "try" for function that does not throw

A try that isn't needed is suspicious… but imho there is a problem with warnings, but that isn't primarily caused by Swift itself. Xcode creates warning as you type, and those often don't help, but just distract, as most of them aren't actually dangerous at all: - Yes, I'm not using this value

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> Aw. It's really bad that labels are gone for closures at the call site . > IMHO, the same principles that encourage the use of labels for "normal" > function calls should prevail here. No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been

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

I'm not sure if the timing of this proposal is coincidence (I recently revived a discussion to remove variadics), but although I stated variadics are not that important, I like this idea much better than the "…"-syntax which looks like a carryover from C… "@variadic" is not only more explicit,

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

> I don't think that non-type generic arguments are enough to create fixed-size > arrays. How would you fill in `struct Vector { ... }`? Fixed-size arrays could be initialized like current arrays: You either give a value to repeat or an array-literal of the right size. There could

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> I would love to have a great web archive for swift-evolution—something with a > really solid search function, good threading, and most of the other niceties > of forums. It'd even be nice to have an upvote feature. But these are all > things that you could do without taking swift-evolution

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> As has been discussed exhaustively in this thread, Swift 3 function labels > don't convey the meaning of parameters, they are almost always prepositional > phrases that don't make sense apart from the primary function name they are > attached to. Why should there be different rules for

[swift-evolution] Public classes with private superclass

I'm running into "class cannot be declared public because its superclass is internal" issues on a regular basis, and I wonder if it wouldn't make sense to allow this combination: It might be less useful as soon as there are abstract classes or generic protocols, but even then I think I'd like

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

Hi there, right now, I have 7115 unread messages in my Swift-folder, so I'm surprised that there hasn't already been a successful proposal to add this feature… afaiks, it wouldn't hurt anybody, and many people want to have it. Therefore: +1, and good luck! ;-)

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Overall, -1. I agree that labels should not affect the type, but imho the current status (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't achieve what it says in the title: For me, that is no question of types at all, but only of names: var a: (Int, z: Int) -> Void =

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

+1 on anything that removes underscores ;-) ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> Let’s discuss something else. Actually there is an easy fix: make all > functions accept optionals. I think this is a really bad idea Indeed. I don't think there is a good motivation to change the status quo: You can't "sugar away" everything; sometimes, you just have to write a line of code

Re: [swift-evolution] [Discussion] mailing list alternative

> A mailing list discourages off-topic and trivial contributions. I could > easily see being sent dozens of emails from a single back and forth. > Increased traffic would force most users to migrate from email to direct > Discourse forums and direct forum use loses the ability to flag,

Re: [swift-evolution] [Discussion] mailing list alternative

> In a mailing list format, everyone is free to start a new thread. Would a forum have a privilege system that stops newbies from starting threads? I've seen no one proposing that. > Whether you invented the language or started learning it yesterday, if you > have a new idea, it comes into

Re: [swift-evolution] Warn about unused Optional.some(())

> I think we should remove the special treatment so that code in the example > above would generate a warning about `()?` being unused. Users can silence it > manually by assigning the result to `_`. Imho Swift already uses warnings excessively, and giving Optional more significance than Void

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

> It seams like there is discussion to be had, comparing these models: > > [A] functions have simple names, and arguments have labeled tuple type > model > [B] model where we strictly require the labels for referring to n-ary > functions (e.g. "insert(cell:, into:)" instead of

Re: [swift-evolution] Annotation of Warnings/Errors

> One of the biggest issues that I saw while teaching Swift to newbies (most > had not programmed before) is confusion based on the early warnings/errors > that swift/xcode gives you as they type. What would happen is that they > would type a variable, and it would say… “You haven’t used this

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

Afaics the motivation has been explained in detail, but actually, you even can declare such a variable as long as it has its own scope: class Test { func f(i: Int) { print(i) } func g() { let f = 1 // hey, works! print(f)

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> Consider even if we had compile-time constants like Vector — > how would that be implemented? What would its backing-type be? Imho it's very simple — UnsafeMutableBufferPointer would be an obvious choice. > It would probably want to use that constant to create a fixed-length

Re: [swift-evolution] [Discussion] mailing list alternative

> I’d encourage those who want web forums to give Mail.app a try. It does a > remarkable job of keeping emails threaded. That doesn't read like we are using the same Mail.app… it's not failing on a regular basis for me, but it's far away from being remarkable (at least not remarkably good).

Re: [swift-evolution] [Discussion] mailing list alternative

> Believe it or not, not everyone in the world can afford the device and data > plan for a JavaScript-rich web front end (I'm aware of the mobile apps). I > remember only being able to buy an iPod Touch myself when it came out. I > *would* be able to participate SE if it existed back then.

Re: [swift-evolution] Warning when omitting default case for imported enums

> Allowing the omission of a default case in an exhaustive switch makes the > addition of a new case to the enum a breaking change. Depending on the context, even with a default the change might be breaking — but without giving notice to the framework client! Additionally, it would feel very

Re: [swift-evolution] A case for postponing ABI stability

Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it. People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph: It shouldn't be hard to

Re: [swift-evolution] A case for postponing ABI stability

> I don’t disagree with your overall point, but I do want to emphasize that > forcing apps to bundle the stdlib and runtime is more than just suboptimal. Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that

Re: [swift-evolution] A case for postponing ABI stability

> I don’t disagree with your overall point, but I do want to emphasize that > forcing apps to bundle the stdlib and runtime is more than just suboptimal. Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that

Re: [swift-evolution] A case for postponing ABI stability

>> - runtime libraries for Swift 4 >> - all system frameworks will need to contain two variants - one compatible >> with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in >> the long run. For how long would you need to keep several versions of the >> framework around? What

Re: [swift-evolution] A case for postponing ABI stability

> Rather than Apple have to commit in perpetuity to ship all relevant versions > of the frameworks, one could imagine more of an app-thinning/install-time > optimization: “thinned” versions of apps would be built and signed without > the shared system frameworks, but with dependency information

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> 2. More on Arrays > > Before, I’ve proposed expressions like “4 * Int” for arrays. But, looking > back, it’s not very Swift-y. I had problems with some forms of the syntax > giving the specification indices in the reverse order of the dereferencing > indices. It looks too quick-and-dirty.

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

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

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

> I thought it was going to be any one subtype of Error, be it a struct, an > enum, or a protocol existential, or Error itself. Imho we should remove the restriction that you can only throw Error-conforming types if typed throws are added: It's a compatibility feature, and if you manually

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

> Wouldn’t that mean that you couldn’t use your Swift library in Objective-C > anymore, at least the error type as an NSError? > That's the meaning of "break with Objective-C" here ;-) — but note that I wrote about allowing to do so, not forcing: Now, we can only declare that something is

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

I never liked the compound name syntax because parenthesis are deeply connected to the application of function, and it breaks with the way selectors are specified in Objective-C. If this topic is touched once again, imho it should be done thoroughly — with a syntax that can really eliminate

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

Maybe I'm missing something obvious (or maybe I'm just generally in favour for case classes ;-), but as the main motivation for the proposal seems to be that enum cases should be more function-like: Why is this desirable? ___ swift-evolution mailing

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> I think everybody agrees (at the very least to some degree) that the current > access level system is too complicated. I'm not sure about that — discussions about adding even more access levels aren't that uncommon, and peoples opinions tend to be surprisingly diverse. I guess that the rate

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

> This is bad faith. The original discussion contains many real life example. "bad faith"? Really? If we have the same interpretation of this phrase in our dictionaries, it's only fitting here as attribute for the sentence following it. I took a position that is extremely easy to attack, yet the

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

It's nothing that is miss all the time, but I was informed about this limitation by the compiler before ;-), so unless there are some unexpected downsides, it should be added — and I wouldn't limit it to instance members: Other parameters could be useful defaults as well (or think of scenarios

Re: [swift-evolution] A concern

Many developers classified Swift as a behemoth right when it was published, so it is a highly personal question wether a language is to complicated or to simple. I guess there are two potential dangers: People have different preferences, and Swift could try to make everyone happy: Using

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

Thanks for the thorough explanation - hope it will spawn some enum-proposals in the future ;-) > This has been discussed several times in the past. If T is itself > Optional, then T | Void | Void == T | Void, meaning you can't safely use > Optional to model potential failure in any generic

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

> I’ll concede that the proposal makes a claim that might very well be > disproved. I would very much like to see an actual example of a public class > that **has** to be public but **shouldn’t** be open for obvious reasons. I > would happily accept being shown wrong on that point. This is

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

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

Re: [swift-evolution] for in? optionalCollection {

Most alternatives already where discussed in swift-user: > Imho the "forEach" solution is flawed, because you can't break the loop, and > the "?? []" isn't perfect either: > I hope the compiler can optimise so that the assembly is as fast as the "if > let" solution, but even if this is the

Re: [swift-evolution] for in? optionalCollection {

> I have a question for you. How do you think we could use this pattern in the > generalised situation: In general ;-) I like things that can be used universally much more than a huge number of special cases. But here, I'm not sure if it's not an increase of complexity: I often if statements

Re: [swift-evolution] Warning when omitting default case for imported enums

>> I'm not sure if I like the concept of having two kinds of enum. > > Why not? Bool-like enums would be declared ‘closed’, and would not require a > default case (but adding a new case would then break ABI). Well, enums are already (relative) complex, and with this addition, there would be

Re: [swift-evolution] Warning when omitting default case for imported enums

> Closed would not be an access level, just an attribute orthogonal to the > others. As Xiaodi pointed out, there's still no agreement on that — so basically I'm saying that I prefer your interpretation, because imho five access levels are already a alarmingly high number. > What do you mean

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

> 1) private to the file (Swift 2 semantics) > 2) accessible only to the current type/scope and to extensions to that type > that are in the current file. Imho the old model had the benefit that it made things like C++ "friend" superfluous, so I prefer 1) over 2). It is simpler, and from a

Re: [swift-evolution] array splatting for variadic parameters

> I didn't get an especially positive response to the proposal at the time, but > it is still very much my preferred solution. I'm convinced that the timing had a very huge impact on the reaction: It was a very busy period, and I had a strong impression that people just wanted to limit the

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

Imho the only good "excuse" for "new private" are playgrounds. They are often forgotten in discussions, but afaics, Swift aims to be a good language for teaching, so there is some impact on its design. Of course, this is only speculation on motivation, as I wasn't involved in the decision to

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

> Personally I’d prefer if we all together with the core team set down > (virtually ^^) and: > > Fully re-evaluated all the access modifier mess and sketched a new future > oriented model on how this should have been regardless it’s breaking change > or not. +1 imho the current situation is an

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> Easy explained - The problem rises indeed not from the added features but > from the fp group that imposes it’s usage in the Standard libraries and “the > swifty way”. I like many features of Swift (or I wouldn’t be here) but I > don’t want to live in Haskel world. And for some reason these

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

>> There is a lot of design overlap. That is the reason why I think we should >> vision variadics as a whole in its future rather than simply repaint … >> postfix to a type annotation keyword @variadics. This will only close the >> doors for some features we might want to add in a future

[swift-evolution] for in? optionalCollection {

This one started over at swift-users, with a question on how to deal with looping over containers that may be nil. Imho the beauty of the feature is that it's simple enough to be explained in the subject line, but here is the "long" story: let test: [Int]? = nil // this is possible now if let

<    1   2   3   4   >