Re: [swift-evolution] Proposal: A standard library Fraction type

Calculating precession time of two frequencies is an example. (consider displaying two waveforms) On Mon, Dec 7, 2015 at 5:43 PM, T.J. Usiyan wrote: > We seem to have become distracted with the whole Time Signature thing. > Time signatures themselves are not Rationals. I

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

> On Dec 19, 2015, at 3:36 PM, Félix Cloutier wrote: > > I'm biased as the pitcher, but I find that an "inheritance" model would be > more straightforward than an inclusive model. > > If I understand you correctly, with this model: > >> enum NetworkException { >> case

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

I agree with this. -1 to the proposal. Charles > On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution > wrote: > > To play devils advocate, take for example UINavigationController in UIKit on > iOS. > > I’ve seen multiple times in multiple projects

Re: [swift-evolution] ternary operator ?: suggestion

How about removing ?: and adding a simple library: struct IfFalse { let condition: Bool let ifTrue: () -> T init(condition: Bool, ifTrue: () -> T) { self.condition = condition self.ifTrue = ifTrue } func ifFalse(ifFalse: () ->

Re: [swift-evolution] Proposal: Add .times method to Integer type

+1 to 5.times{stuff} from me. I much prefer library functions to language extensions. -- Howard. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

+0. This seems reasonable, and a lot of the arguments are compelling. The argument put forth about library design especially so. But coming from C++, where I have to prefix nearly every method in my classes with virtual, I'm worried that we could end up with the same problem in Swift. We don't

Re: [swift-evolution] Proposal: Add .times method to Integer type

-1 from me. It is simple enough for an extension and provides little benefit as a standard library inclusion. On Sun, Dec 20, 2015 at 9:10 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > +1 to 5.times{stuff} from me. I much prefer library functions to language >

Re: [swift-evolution] [Review] Require self for accessing instance members

* What is your evaluation of the proposal? I am against. * Is the problem being addressed significant enough to warrant a change to Swift? No. Quoting the proposal: > Lets the compiler warn users (and avoids bugs) where the authors mean to use > a local variable but instead are

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

and you get to test betas of future iOS releases anyway, so if something breaks, you'll catch it and release a fix. That assumes that all apps get updated when new OS releases come out, and that's not true. Many apps stop being maintained, but they may have many users, and Apple does whatever

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

Also in future versions features may go away meaning older libraries may assume that greater than swift 2 is all that is needed to imply compatibility. Also libraries may be written against features they may not know which version of swift it will get into. Additionally certain features aren't

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 20, 2015, at 3:14 AM, Brent Royal-Gordon > wrote: > > Anyway, my point remains: this _SwiftNativeNSError should use a userInfo > property on your ErrorType to populate NSError.userInfo. There should be no > need to go through the full rigamarole of calling

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

I second placeholder as the most rational keyword. Every description of the distinct usage of type alias refers to is a placeholder type. placeholder is one word(circumventingCase_issues) and is more descriptive of what it is than associated*. Seems like an easy win. Is there a some reason I am

Re: [swift-evolution] [Proposal] function "return" optional keyword.

-1 on inferred return type and omitting return with func Both features are actually available in the language as-is, just not with the func keyword: let someInferredFunction = { _ in 5} // () -> Int When teaching Swift we actually teach func + return keywords together, they make it easy to see

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

> You even have a great keyword to search for, right there. Good point - we are lucky that Apple has so much influence to make "swift" already a useful search term so we don't have to look for "swiftlang" ;-) Still undecided wether this argument is a bad justification for cryptic names in

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

> The main reason to use `associated` is because the feature is called an > "associated type". If we're willing to rename the feature to "placeholder > type", then `placeholder` would be a good keyword. good point - maybe it's because I'm no native speaker, but for me "associated type" is just

Re: [swift-evolution] Brace syntax

On Sun, Dec 20, 2015 at 8:12 AM, Alexander Regueiro via swift-evolution < swift-evolution@swift.org> wrote: > > There have also been a few votes against removing braces, but these seem > to be reactionary. Could any of you perhaps clarify why you want to keep > them, or is it just the “change is

Re: [swift-evolution] Brace syntax

> just not sure weather it would be good to put more complexity into Xcode Braceless mode is sort of a special case. It could be useful, even for people prefer braces, to temporarily hide some of the more, uh, decorative elements - and vice versa. The option to switch back and forth, for

Re: [swift-evolution] Brace syntax

Andrey's post encourages me to veer into the merits of significant whitespace vs braces. This is probably unwise of me, since we're not all going to agree any time soon, but I can't resist pointing out an example: var foo:

Re: [swift-evolution] Brace syntax

Yes, that is the point. If you use braces in Swift, you will naturally gravitate to all sorts of personalized strategies. Now this is possible with significant whitespace (e.g.: Python uses the semicolon to put multiple statements on the same line) but not nearly as common. On Sun, Dec 20, 2015

[swift-evolution] [Proposal] Lock file for Swift Package Manager

Lock File for Swift Package ManagerIntroduction A Package.lock file containing list of resolved dependencies generated by swiftpm. Motivation Package.lock file can be helpful in situations like : Reproduce exact versions of dependencies on different machine * Multiple developers working on a

Re: [swift-evolution] rethrows as first-class type annotation

Hi Alexandre, I think for this use case we don't actually need 'rethrows' to become a part of the closure type, we just need the compiler to allow and "instantiate" it in more places. The case where we would need 'rethrows' to become a first class part of the type system is if we wanted

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

-1 I understand the idea. But we would still need a replacement for “typealias” because “Element: typealias” says “Element is a type alias” and not “Element is an associated type”. Also, it would be difficult to add inheritance clauses and default values. “Element is an associated type that

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 20, 2015, at 12:35 AM, Brent Royal-Gordon > wrote: > > I don't know if it can actually be private, but it should be invisible to > developers, and considered an implementation detail. It might also make sense > to retrieve the `userInfo` from `swiftError` on

Re: [swift-evolution] rethrows as first-class type annotation

Hi Dmitri, This is a better example than any that I have come up with so far as to why “rethrows” should be a part of the signature. You shouldn’t have to use “try!” to apply a non-throwing function, like {print($0)} to “forEach”. — Sasha > On 20 Dec 2015, at 13:37, Dmitri Gribenko

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

I like placeholder too. However, it also suffers from the lack of “type” in it. So, the real comparison is between: placeholder — associated placholdertype — associatedtype > On Dec 20, 2015, at 10:06 AM, Andrew Hoos wrote: > > I second placeholder as the most rational

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

> Frankly, I think having `final` in the language at all is a mistake. While I > agree that we should prefer composition to inheritance*, declaring things > final is hubris. The only reasonable use case I've seen is for optimization, > but that smacks of developers serving the compiler rather

Re: [swift-evolution] Brace syntax

> I don't know many people who have experienced a large variety (8+?) of > programming languages and prefer Python's forced indentation Count me as one. I'd prefer Swift to have Python-style indentation, just on the grounds of braces being stupid (why would you want to enter the same scope

Re: [swift-evolution] Proposal: Add .times method to Integer type

The Foundation framework is being ported to other platforms and it has CGSize and NSDate (but not NSImage/UIImage). For the rest, the Swift package manager will probably fulfill that role, no?

Re: [swift-evolution] Brace syntax

+1 for significant whitespace instead of braces. But as others said, ain't gonna happen... :( Sent from my iPhone > On 20 Dec 2015, at 02:39, Alexander Regueiro via swift-evolution > wrote: > > Has anyone considered removing braces from the Swift language? The main

[swift-evolution] Proposal: Make braces optional much like semicolons.

// braces are optional here but you could still put them in if you want to for i in 0..<10 for j in 0..<5 if i % 2 == 0 print(i+j) print(i*j) // braces are necessary because “print" is on the same line as ”if" for i in 0..<10 for j in 0..<5 if i % 2 ==

Re: [swift-evolution] Using "where" to filter an array

That would be a weak -1 for me too, but only because I don't like the where syntax on control structures. Félix > Le 20 déc. 2015 à 01:31:28, Jacob Bandes-Storch via swift-evolution > a écrit : > > A weak -1. > > I'm not certain that my argument holds up very

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

There was a thread for this posted yesterday: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003631.html Stephen > On Dec 20, 2015, at 10:17 AM, Amir Michail via swift-evolution > wrote: > > // braces are optional here but you could still

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

> On Dec 20, 2015, at 10:19 AM, Stephen Celis wrote: > > There was a thread for this posted yesterday: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003631.html > Much of that discussion doesn’t consider the possibility of making braces

Re: [swift-evolution] Brace syntax

Interesting discussion. Thank you for the points, Charles and Andrey, in particular. I too consider braces to be “redundant noise” in the same way semicolons are for single-line statements, among other syntactical features. Indeed, it feels like I’m stating myself twice whenever I write them.

Re: [swift-evolution] [Proposal] function "return" optional keyword.

Also since the example rewrite is a single line function it could be rewritten as: def f2(input: Integer) : Integer = input match { case _ if input > 10 => 10 case _ if input < 0 => 0 case _ => input } Even with the overkill of pattern matching it — it still is easy to

Re: [swift-evolution] ternary operator ?: suggestion

The complaint that you have about Javascript is more a function of it not being a strongly typed language. If you were to write a function with the type of return specified and the code inside the function (because of a single character) end up changing type for the return value or a future

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

I have to admit that Radek’s comment about “for … in? …” meaning an iteration over a SequenceType containing Optional Values is valid. But I think “for? … in …” is worse because it separates the “?” from the thing that is the Optional thing. Consider: for? x in array { … } vs. for x in?

Re: [swift-evolution] Proposal: Port open source productivity apps to Swift to gain insight into language evolution.

> On Dec 20, 2015, at 12:19 PM, Tino Heth via swift-evolution > wrote: > > >> My recommendation would be to port the open source TeXmacs to Swift. It’s by >> far the best coded and powerful productivity app that I have seen and should >> have replaced TeX/LaTeX

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

>> In Objective-C, I liked that fast enumeration over an NSArray that was nil >> and one that was empty could be handled with the exact same code: >> >> NSArray *strings = nil; >> for (NSString *string in strings) { >> … >> } > > One thing we've discussed is adding attributes to import nil

Re: [swift-evolution] [Pitch] make @noescape the default

> On Dec 19, 2015, at 7:51 PM, Kevin Ballard via swift-evolution > wrote: > > -1 > > The standard library is not representative of how closures are commonly used. > Notably, the standard library never executes anything asynchronously (an > extremely common use of

Re: [swift-evolution] [Proposal] Lock file for Swift Package Manager

Personally, I’d be more in favour of having something similar to Cargo (Rust’s package/crate manager): 1. `swift build` Almost the same as it is now, expect if there’s no Package.lock it creates one and subsequent builds use the same dependencies. 2. `swift build --update` or maybe eventually

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

> On Dec 20, 2015, at 1:06 AM, Kevin Lundberg via swift-evolution > wrote: > > Interesting proposal, but how would it work with closures that take two > or more params? What would the following expression become: > > [1,2,3,4].reduce("", { $0.description +

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

> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution > wrote: > >> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I don't think `required` captures the intended meaning *at all*. You're

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

> On Dec 20, 2015, at 10:54 AM, Amir Michail wrote: > > Much of that discussion doesn’t consider the possibility of making braces > OPTIONAL as shown in the examples. Sure. This is a point you could have made in that discussion. I think in general the preference is to reply

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

On Sun, Dec 20, 2015 at 8:17 AM, Amir Michail via swift-evolution wrote: > // braces are optional here but you could still put them in if you want to > for i in 0..<10 > for j in 0..<5 > if i % 2 == 0 > print(i+j) > print(i*j) > -1.

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

Although I am not for braces being optional and using tab / indentation for scope, the forcing of using braces for one line scopes is overkill IMHO. If there is scope that is multiline though I would probably include scope on all of them (there is one multi-line scope in that example). So +1 /

Re: [swift-evolution] ternary operator ?: suggestion

Paul, does the proposed operator short-circuit like ternary does (i.e. is only the active case evaluated)? – Steve > On Dec 19, 2015, at 11:42 AM, Paul Ossenbruggen via swift-evolution > wrote: > > Thanks, great feedback! > > Good point about the floats, that is

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

I think we should be moving towards feature detection over swift version detection Sent from my iPhone > On 20 Dec 2015, at 06:32, Dirk Schreib via swift-evolution > wrote: > > >> On 20 Dec 2015, at 07:01, Jordan Rose via swift-evolution >>

Re: [swift-evolution] Brace syntax

Thanks for sharing your thoughts. I hear what you’re saying, but not sure any of these points are substantial enough to outweigh the benefits. > Having written a lot of Python code over the last seven years, I definitely > prefer braces to significant whitespace, not because I enjoy looking at

Re: [swift-evolution] [Proposal] function "return" optional keyword.

I honestly don’t have a problem with having to say `return` inside functions. That’s not necessarily a -1, but I’m reluctant to say +1 when _even I_ don’t really have the problem with extra verbosity. *However*, as others pointed out, having to type `return` is a bit tiring in the context of a

Re: [swift-evolution] Fluent syntax (replacing void with a useful default return value)

Same as Kevin. I like this pattern, but an implicit behavior of this sort doesn’t seem appropriate. — Radek > On 20 Dec 2015, at 04:05, Kevin Ballard via swift-evolution > wrote: > > This kind of pattern (which I've always considered the "builder pattern") is >

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

> My experience with other languages is that [...] unless you're a Boost > maintainer, people tend to target one version of the language anyway, either > the older one using a workaround portable to the newer version, or the new > version without regards to people stuck behind. That's not how