Re: [swift-evolution] Property Getter Return Statement

> > I’m minorly opposed, because it feels like a slippery slope. What about > function bodies? etc > > func foo() -> Int { 3 } // should this be allowed? Yes, why not? What is fundamentally different about a function body compared to a getter body (or a closure body ;-)) that means, if we ac

Re: [swift-evolution] [Proposal] Random Unification

> On 11 Oct 2017, at 18:21, Cory Benfield wrote: > > I strongly recommend building the padded room. > I strongly recommend that the padded room have a door in it. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/ma

Re: [swift-evolution] [Proposal] Random Unification

> On 11 Oct 2017, at 18:01, Kevin Nattinger wrote: > > IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array > (RandomAccessSequence?), they should just be for convenience and with a sane > default RNG*, and users that need more should just use methods on the RNGs > directly. >

Re: [swift-evolution] [Proposal] Random Unification

I’m a bit late to the party on this one, but has anybody considered the fact that you need a way for the user of the interface to override the default random number source? For example, some applications require a cryptographically secure source, others might eschew perfect entropy for speed. S

Re: [swift-evolution] (Pitch) Conformance Regions

> On 30 Mar 2017, at 18:07, Ross O'Brien via swift-evolution > wrote: > > > It has become an idiom of Swift to declare an extension to a type for each > protocol we want it to conform to, for reasons of code organisation and > readability. This can be true even if conformance to the protoc

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution > wrote: > > > Our philosophy in general, however, is to default to the behavior which > preserves the most flexibility for the library designer. Actually, I thought the philosophy was to preserver type safety. When did that

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution > wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases aren't > source-breaking is a mo

Re: [swift-evolution] for-else syntax

> On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution > wrote: > > > on Fri Feb 03 2017, Dimitri Racordon wrote: > >> Talking of Python, Swift is not Python and the argument not to >> implement a feature because its semantics conflict with the semantics >> of a similar looking feature

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

I’m not a fan of moving to a forum or equivalent, however, I’m coming round to the idea. I’d be fine with it as long as the following features were included: * configurable so that I am emailed all new topics and new posts (or RSS equivalent) * Support for markdown, ideally the GitHub dialect

Re: [swift-evolution] for-else syntax

> On 3 Feb 2017, at 09:27, Dimitri Racordon via swift-evolution > wrote: > >> Talking of Python, Swift is not Python and the argument not to implement a >> feature because its semantics conflict with the semantics of a similar >> looking feature in another language is bogus. I don’t see the P

Re: [swift-evolution] for-else syntax

> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution > wrote: > > ah! I forgot about the break semantics, that’s definitely one for the con > list. > > I like Nicolas’ solution, clear to read. > >> On 1 Feb 2017, at 18:18, Nicolas Fezans wrote: >> >> I tend to write this kind of trea

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

> On 25 Jan 2017, at 23:34, Erica Sadun via swift-evolution > wrote: > > >> On Jan 25, 2017, at 1:05 PM, Ted Kremenek via swift-evolution >> wrote: >> >> I have no problem with the project moving to forums instead of the Mailman >> mailing lists we have now — if it is the right set of trad

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

> On 26 Jan 2017, at 20:45, charles--- via swift-evolution > wrote: > > +1 > > Strongly in favour of this one. One of those things that seems obvious in > retrospect > > It would also make the language more enjoyable to code in. For you maybe. I like having the issues pop up and then disapp

Re: [swift-evolution] Strings in Swift 4

> On 20 Jan 2017, at 11:55, Maxim Veksler wrote: > > Please see discussion inline. > > On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira > wrote: > > > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution > > wrote: > > > > One ask - make string interpolation great again? > > > > Takin

Re: [swift-evolution] Strings in Swift 4

> On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution > wrote: > > One ask - make string interpolation great again? > > Taking from examples supplied at > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation > > "Column 1: \(n.format(radix:16, width

Re: [swift-evolution] Reduce with inout

> On 18 Jan 2017, at 12:45, Georgios Moschovitis > wrote: > >> That’s what I thought also until just now, but then why wouldn’t you just >> use a for … in loop? > > the former gives a hint about what someFunction (and the for-loop) is doing. Whereas the latter explicitly lays out what is

Re: [swift-evolution] Reduce with inout

> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution > wrote: > > Thought: if the idea is performance and not drop-in replacement, why force > the user to incur two copies? If the initial value were inout, this function > would be more unambiguous even without a new name, and at _worst_

Re: [swift-evolution] Reduce with inout

> On 18 Jan 2017, at 02:17, Xiaodi Wu via swift-evolution > wrote: > > A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`. > > It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is > incorrect since, as Charles pointed out to Dave, it's not `x` that's mutated >

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On 17 Jan 2017, at 11:53, Alex Blewitt wrote: > >> >> On 17 Jan 2017, at 11:46, Jeremy Pereira >> wrote: >> >>> >>> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: >>> >>> >>>> On 17 Jan 2017, at 11:10, Jer

Re: [swift-evolution] Removing var keyword in protocol property reqirements

> On 18 Jan 2017, at 05:38, Vinnie Hesener via swift-evolution > wrote: > > The var keyword in protocol property requirements is misleading. > > From the docs: > *If a protocol requires a property to be gettable and settable, that property > requirement cannot be fulfilled by a constant stor

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: > > >> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >>> wrote: >>> >>> I re

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On 16 Jan 2017, at 16:38, Amir Michail via swift-evolution > wrote: > > >> On Jan 16, 2017, at 10:55 AM, Tony Allevato wrote: >> >> As a general rule of thumb, changes to the language should not require the >> use of an IDE in order to return them back to the level of usability that >> w

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution > wrote: > > I really hate to bring Java up, but I really do think it got at least one > thing right with its error system, namely that one subset of error (namely > `RuntimeException`), wouldn't be enforced by the compiler, but cou

Re: [swift-evolution] Move placement of 'throws' statement

> On 9 Jan 2017, at 22:11, Anton Zhilin via swift-evolution > wrote: > > I also thought about sum types as implementation of errors, but selecting > between Tyler’s and John’s syntaxes, I would pick the latter. Compare: > > let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double > )) >

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

For me the link is broken and your GitHub account doesn’t seem to contain a clone of Swift-Evolution. > On 8 Jan 2017, at 03:46, Carlos García via swift-evolution > wrote: > > Hi all, > > Here’s a draft proposal to change > if let construction for obtain let. Proposal is at: > https://github

Re: [swift-evolution] Move placement of 'throws' statement

-thislooksfun (tlf) > >> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution >> wrote: >> >>> >>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution >>> wrote: >>> >>> >>> >>> I'm sorr

Re: [swift-evolution] Move placement of 'throws' statement

> On 3 Jan 2017, at 16:29, John McCall via swift-evolution > wrote: > > > > I'm sorry if people dislike the placement of "throws", but that ship has > sailed, > and any attempt to "fix" it at this point is just going to cause problems for > negligible benefit. > > As I see it, the current s

Re: [swift-evolution] "with" operator a la O'Caml?

> On 21 Dec 2016, at 14:07, Matthew Johnson wrote: > >>> >>> The performance hit is likely a bit larger if you *don't* use a mutable >>> property and instead create a whole new instance. >> >> How is >> >>let a = SomeStruct() >>var b = a >> >> not creating a new instance? > > Of c

Re: [swift-evolution] "with" operator a la O'Caml?

> On 20 Dec 2016, at 17:32, Derrick Ho via swift-evolution > wrote: > > Jeremy, > > The problem you present is not a mutability problem but rather a cache design > problem. If your hash value truly is expensive then you only want to > calculated it when you need to... > > struct Person: Ha

Re: [swift-evolution] "with" operator a la O'Caml?

> On 20 Dec 2016, at 13:10, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Dec 20, 2016, at 4:32 AM, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 20 Dec 2016, at 07:54, Pierre Monod-Broca via swift-evolution &g

Re: [swift-evolution] "with" operator a la O'Caml?

> On 20 Dec 2016, at 07:54, Pierre Monod-Broca via swift-evolution > wrote: > > But for a struct to be immutable, you don't need all its properties to be > let. (I guess that's Derrick's point) Yes you do. Consider struct Person: Hashable { let firstName: String let lastName: String

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

The Swift compiler can give you the information that you want. Here is what you can do: Write a Swift source file that creates an instance of the type you want to test and then tries to access each of the private members. Write a shell script to compile this source file i a module with the fi

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

> On 8 Dec 2016, at 12:52, Aron Lindberg via swift-evolution > wrote: > > I realise the general opinion here seems to be that we don't want any more > changes to the access modifiers and I can understand why, but please take a > look at the use case below: > > "fileprivate" is needed for cer

Re: [swift-evolution] About "default" keyword in switch statement

> On 6 Dec 2016, at 04:11, 星野恵瑠 via swift-evolution > wrote: > > p.s. > > I've read this mail and totally understand that Swift is designed to be > familiar with C family languages, which "default" is widely used. > https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md Di

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

> On 2 Dec 2016, at 15:44, Benjamin Spratling wrote: > > I see where you're going with that. So it's an artifact from Java and C++, > too? :) > > I was recently doing a review of music notation, and one of the problems is > that it has multiple ways of doing exactly the same thing. Anyone

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

> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution > wrote: > > I agree that there is a major problem with “subclasses must override these > methods”. We have no capability to describe this in Swift, and frankly, it > feels like something that ought to be enforced. It’s almos

Re: [swift-evolution] Add code to super methods.

> On 29 Nov 2016, at 16:55, Aron Lindberg via swift-evolution > wrote: > > While I agree with most of your points Dave, I think forgetting to call super > is very much a (hard to debug) real world problem today. I don’t. I’ve done it a few times but I don’t remember ever having a hard time d

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

> On 21 Nov 2016, at 08:42, Rien via swift-evolution > wrote: > > Sure you can do that, but I rather write: > > struct A.B {…} > > than > > extension A { struct B {…} } > > The first seems much “swiftier” to me. Hmm, objectively, it’s not “swiftier” is it, because Swift has had the extens

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> On 29 Oct 2016, at 03:22, Xiaodi Wu via swift-evolution > wrote: > > > Given the adage here that code is more frequently read than written, it is > unreasonable to require someone to master both "form union" and the union > operator when one of these will do. While you and I are comfortabl

Re: [swift-evolution] guard let x = x

> On 29 Oct 2016, at 02:10, Erica Sadun via swift-evolution > wrote: > > Sounds good to me. Leaving the gist in its updated state (a little further > from the last time) for the record. I like the first part, even though I disagree that `if let foo = foo` conflicts with DRY principles. Howev

Re: [swift-evolution] Promises, Futures and the death of the callback hell

> On 29 Oct 2016, at 01:47, Xiaodi Wu via swift-evolution > wrote: > > Async and related topics are deferred until the spring; I would imagine > promises fall into the same basket. So you are promising that we will discuss futures and promises in the future…

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 13:15, Haravikk wrote: > > > I'm inclined to disagree; the keyword wouldn't be much different from the use > of the is keyword to test a type (I even suggested using it since it's > shorter than matches and wouldn't require a new term), both are run-time > operations exc

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 08:13, Rien via swift-evolution > wrote: > > I have tried to like this because at first it seems like a good idea. > But having let it shimmer for a while, I simply cannot muster the enthusiasm > for it. Using “~=“ does not ‘feel’ right to me. Especially for a code > brea

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

> On 19 Oct 2016, at 16:13, Guoye Zhang wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>> >>> Currently, Swift Int family and UInt family have compact representations >>> that utilize all available valu

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution > wrote: > > Currently, Swift Int family and UInt family have compact representations that > utilize all available values, which is inherited from C. However, it is > horribly inefficient to implement optional integers. It takes doub

Re: [swift-evolution] [Out of scope][Gibberish]

So sorry, I meant to delete Swift-evolution from the cc list but forgot. Apologies for the off topic post. > On 17 Oct 2016, at 10:12, Jeremy Pereira > wrote: > > >> On 14 Oct 2016, at 20:11, Ted F.A. van Gaalen via swift-evolution >> wrote: >> >> >>> On 14 Oct 2016, at 07:16, Daniel Dua

Re: [swift-evolution] [Out of scope][Gibberish]

> On 14 Oct 2016, at 20:11, Ted F.A. van Gaalen via swift-evolution > wrote: > > >> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution >> wrote: >> >> 1. “honor” is mis-spelled in “weird queen’s dialect”. > > I'm sorry, but I throw an exception at this; when you say "weird queen's

Re: [swift-evolution] private & fileprivate

> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution > wrote: > > I agree with Ted that I would have expected the inner members of a class to > be private by default. (Not a big deal if I have to explicitly prefix most of > my concerned vars now - but it is just different to what I wou

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution > wrote: > > > While Swift is mainly a statically typed language, recompilation or > additional > compilation and somehow link it al together is obviously necessary at run > time, > each time a dynamic structure is defined

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On 6 Oct 2016, at 03:08, Greg Parker via swift-evolution > wrote: > > >> On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> Now, as for naming: I like using the leading "C" convention ("CLibc") >> because it leaves us room for introducing an overlaid versi

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On 5 Oct 2016, at 15:29, Haravikk via swift-evolution > wrote: > > > I agree with Tim; I'm a +1 for switch! for a convenient means of erroring > out, but I think switch? is a bit too different from normal usage of the > question-mark. > > One other alternative might be if there could be s

Re: [swift-evolution] Currying/Partial Application

You can emulate it with a closure func myFunc(a: Int, b: Int, c: Int) -> Int { return a + b + c } let partial = { (b) -> Int in return myFunc(a: 5, b: b, c: 7) } let ans = partial(6) // 18 It’s not ideal because you lose the argument label, but I think they’re going to fix that one day. > On 6

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On 3 Oct 2016, at 22:41, Kevin Ballard via swift-evolution > wrote: > > On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote: >> Swift developers frequently use string interpolation as a convenient, >> concise syntax for interweaving variable values with strings. The >

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On 3 Oct 2016, at 11:14, Adrian Zubarev via swift-evolution > wrote: > > I know that there is this note in Commonly Rejected Changes: > > Remove support for default: in switch and just use case _:: default is widely > used, case _ is too magical, and default is widely precedented in many C

Re: [swift-evolution] class/struct inner member access scope classifier

> On 27 Sep 2016, at 14:20, Zach Waldowski via swift-evolution > wrote: > > > > > On Tue, Sep 27, 2016, at 01:34 AM, Jeremy Pereira via swift-evolution > wrote: >> As for dropping file private, why? You don’t have to use it if you don’t >> want to, so it’

Re: [swift-evolution] class/struct inner member access scope classifier

> On 26 Sep 2016, at 20:58, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hello! Hope you are all OK! > > > As far as I can see without binoculars, the “fileprivate” acces modifier > could be dropped, were it not for source compatibility reasons... > > Unless I am missing somethin

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> > Annotating that a parameter of a closure should not escape the closure is > probably a worthwhile thing to have, anyway. Currently we only allow that for > function-type parameters, but there are other parameters you might give (such > as the pointer in `String.withCString()`’s closure) wh

Re: [swift-evolution] Propagating Optionals

> On 26 Sep 2016, at 00:26, William Sumner via swift-evolution > wrote: > >> >> let roomCount = john.residence.numberOfRooms >> >> // error: value of optional type 'Residence?' not unwrapped; did >> you mean to use '!' or '?'? >> >> As general rule of thumb, whenever I get an error and the

Re: [swift-evolution] Bls: Range that goes both ways

> On 21 Sep 2016, at 11:44, Mr Bee via swift-evolution > wrote: > > > But after I thought about it again, I think half-opened range doesn't really > make any senses. The ..< operator (and my proposed ..> operator) should be > removed. Or we have to accept the consequences that we also need t

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

> On 6 Jul 2016, at 00:11, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are so

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

> > * What is your evaluation of the proposal? -1 The first “problem” given in the motivation is "As an orthogonal attribute of function types, its interaction must be specified with every other aspect of function types” Errr, well yes, of course. Why is it a problem that orthogonal co

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

> On 22 Jun 2016, at 17:27, Brandon Knope wrote: > > Of course \ is not needed a lot but when it is, *it is inconvenient for > *some* people*. I am not making this up. You can cite several other users > from this very thread. That’s the point. Convenient key stroke sequences should be used fo

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

> On 22 Jun 2016, at 17:02, Brandon Knope wrote: > > No it shows where your hand frequently is also And you don’t think there is a correlation between where the frequently pressed keys are and where your hands are? If you were needing to press the \ key a lot, there would be a hotspot over it

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

> On 22 Jun 2016, at 16:41, Brandon Knope wrote: > > My point was not to argue for the removal of \. My point was that there is a > measurable way to test the usability of such a key Your heat map doesn’t test the usability of a key, it tests the frequency with which it was pressed. The fact

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

> On 22 Jun 2016, at 09:39, Goffredo Marocchi via swift-evolution > wrote: > > Sorry, but can you explain why the character used to escape strings is > also the best choice to do Variable value extraction/String interpolation? > They are two different concepts. No they are not. Escap

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

I find it somewhat disturbing that we are now trying to base language design around the layout of a US English keyboard. “\” on my keyboard (British Macbook Pro Retina) is right next to the return key. It’s also much closer to the parentheses characters than $ is and (if you assume we are going

Re: [swift-evolution] Normalizing operator's types

> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution > wrote: > > Hi Swift, > > Since the "removal" of curried function, I am looking for some elegant ways > to work with partial functions (and reduce creation of closure and nested > func for the developper). > > And now I a

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

> On 8 Jun 2016, at 03:10, Brandon Knope via swift-evolution > wrote: > > On the other hand... > > The first is rather clever and beautiful looking...making it somewhat Swifty. “Clever” is not necessarily good. “Clever” implies cleverness is needed to understand it. “Beautiful” is a subje

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

> On 7 Jun 2016, at 17:47, Brent Royal-Gordon wrote: > >> I disagree. We are discussing how to annotate a function in some way so that >> the compiler knows that the code following it will never be executed *and* >> so a human who reads the declaration knows that it does not return. “Never" >

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> IMO dictionary [Type1:Type2?] is a special case where you need to use > myDict.keys.contains(keyValue) first to determinate if you have a value for > key and after this you can get the value itself(which is Optional). I don’t understand why you think it is a special case. The return type of

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

> On 6 Jun 2016, at 16:37, Vladimir.S via swift-evolution > wrote: > > My opinion is based on this message: > > On 05.06.2016 23:16, L. Mihalkovic via swift-evolution wrote: > > > > FWIW, in the rejection of SE-0097 > >

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

> On 31 May 2016, at 18:53, Charlie Monroe via swift-evolution > wrote: > > The way I see it and would use it: > > Directives: > > #error - fatal error, the binary shouldn't compile - e.g. unknown OS host and > the code depends on underlying OS features. > > #warning - it is a big deal, but

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

> On 24 May 2016, at 12:33, Haravikk via swift-evolution > wrote: > > >> On 23 May 2016, at 20:19, Dany St-Amant via swift-evolution >> wrote: >> >> Challenge accepted… Removed the if/else if, at the cost of double function >> call to a tri-op: >> >> extension Bool { >> func as01() ->

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

> On 19 May 2016, at 23:29, Chris Lattner via swift-evolution > wrote: > > > * What is your evaluation of the proposal? +1 I think I would find myself using this in loads of places, if it was implemented. One question: what is the downside of making these functions `rethrows` and al

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

> On 19 May 2016, at 18:06, Krystof Vasa wrote: > > I'm wondering which scenario this is actually wanted behavior: > > - strings that are for user interaction? Definitely not. There would almost certainly be other manipulation going on that renders this moot for user facing strings, for insta

Re: [swift-evolution] Winding down the Swift 3 release

> On 19 May 2016, at 15:44, Zach Waldowski via swift-evolution > wrote: > > > > Much like people are expressing relief that the compatibility goals for > the language are not being dictated by specific timelines, I would be > wholly concerned if any of Swift's goals were being defined by winn

Re: [swift-evolution] Winding down the Swift 3 release

> On 19 May 2016, at 10:47, Brent Royal-Gordon wrote: > >> Is completing the generic system fundamental or not? I’d say it is vastly >> more fundamental than removing C style for loops, wouldn’t you? > > Oh, come on. Removing the C-style for loop is not what took up time in this > release cyc

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

> On 19 May 2016, at 13:30, Krystof Vasa via swift-evolution > wrote: > > See this example that demonstrates how it's pretty much unusable (IMHO), > since whenever you refer to the instance as to the protocol, the default > implementation gets invoked: > > protocol MyProtocol { } > > extens

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

-1 This seems to me like crippling string interpolation just because sometimes we make mistakes. 99% of the time, if I interpolate an optional, it’s because I want it that way. I don’t want to have to put up with a warning or write the same boilerplate 99% of the time just to flag up the 1% mor

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

> On 18 May 2016, at 21:53, Erica Sadun via swift-evolution > wrote: > > Just some context: > > "We have a few conjoined keywords already (typealias, associatedtype, > fallthrough). In the discussion about these terms, we decided that these > read best when all lowercase, because they are t

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

> On 18 May 2016, at 21:51, Leonardo Pessoa via swift-evolution > wrote: > > I may be wrong but I don't remember any other case of a keyword in > Swift composed of two or more words, dynamicType, associatedtype, typealias, privatefile > so I believe these should be > exceptions. I would agr

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

> On 18 May 2016, at 04:30, Chris Lattner via swift-evolution > wrote: > > > * What is your evaluation of the proposal? +1. A major improvement over the current system. I’m fine with the suggested syntax in general. I’ll be using it rarely enough that it won’t bother me what is eventu

Re: [swift-evolution] Winding down the Swift 3 release

> On 17 May 2016, at 23:45, Eric Wing via swift-evolution > wrote: > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > makes my life harder, but on the flip-side, I don’t want to be stuck > with yet another broken language and ABI. I want this done right > because it wil

Re: [swift-evolution] Winding down the Swift 3 release

> On 17 May 2016, at 14:38, Rod Brown wrote: > > While on the face of it, you are correct, the goals have changed > dramatically, I think you are being unfair. The goals changed dramatically last week. It’s there in the git history. Last week was *after* the first developer preview of Swift

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

+1,000,000 I hate the K&R brace style. :) What I would really like is something similar to Eclipse’s system that pretty much allows you to customise almost every aspect of the Java formatting style to your own preferences and also export them in a handy XML file. > On 16 May 2016, at 22:42,

Re: [swift-evolution] Winding down the Swift 3 release

> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution > wrote: > > Quite sad we could not get into ABI stability for Swift 3... but are we > talking Swift 3.1 or 4.0? Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is stil

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Hi, I’m a +1 on the proposal, I think it’s a no brainer, but I do have one question... What is the reasoning behind repeating the module name in the type name? e.g we have `Dispatch.DispatchQueue`. Why not `Dispatch.Queue`? It seems a bit pointless for the Swift team to go to all that effort t

Re: [swift-evolution] Standard library 'Data' type pre-proposal

I think there is a typo on the initialiser from a hex tuple string. The external name of the first parameter should not be `base64EncodedString`. In fact, I’m not sure why base64String and hexTupleString aren’t OK for the external name of first parameter of those initialisers. > On 12 May 201

Re: [swift-evolution] Standard library 'Data' type pre-proposal

> On 11 May 2016, at 10:37, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > ... > Some thoughts: > > - It's not clear if the methods to convert to and from base-64 encoded data > are necessary. The state flag that tries to mark whether or not a Data > represents

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On 10 May 2016, at 22:27, Tyler Cloutier via swift-evolution > wrote: > >> > And isn’t this the point really. Yes there are many different ways of doing > something, but there should be one obvious way. IMHO, there is nothing more > obvious than just > > repeat { > > } Yes there is:

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

> On 20 Apr 2016, at 19:24, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 20 2016, Tino Heth wrote: > >> Increment/decrement operators, currying, tuple splat and even the >> C-style for loop have already been deprecated, and although I would >> have preferred to keep some of th

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

> On 20 Apr 2016, at 15:56, Tino Heth <2...@gmx.de> wrote: > > >> The question is whether the downside to variadic parameters is really enough >> to justify _removing_ an existing language feature. >> >> The burden of justification should be on those people wanting to change the >> language,

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

> On 20 Apr 2016, at 13:10, Haravikk wrote: > > >> On 20 Apr 2016, at 11:44, Jeremy Pereira >> wrote: >>> Pros: >>> • Slightly cleaner syntax at call-site. >>> • Possibly optimisations unavailable to Array passing? >> >> • Makes calling C and Objective-C functions with variadic param

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

> On 20 Apr 2016, at 18:16, Chris Lattner via swift-evolution > wrote: > > > * What is your evaluation of the proposal? -1 Addressing the issues cited in the proposal: > • dynamicType remains an exception to Swift's lowercased keywords rule. > This change eliminates a special c

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

> On 21 Apr 2016, at 02:14, Brent Royal-Gordon via swift-evolution > wrote: > >> 1) “Self" differs from “self” by just the first letter being capitalized. >> Regardless of case, it is confusing for the terms “self” or “Self” or “SELF” >> to mean different things from within the same context.

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

> On 20 Apr 2016, at 15:40, Erica Sadun wrote: > > >> On Apr 20, 2016, at 5:09 AM, Jeremy Pereira >> wrote: >> >> >>> On 19 Apr 2016, at 17:24, Erica Sadun via swift-evolution >>> wrote: >>> >>> Short of a complete rethink of closure syntax, requiring parentheses there >>> would n

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

> On 20 Apr 2016, at 08:02, Vladimir.S via swift-evolution > wrote: > > Great points! We definitely have some mess with tuples¶meters list in > current Swift. Especially after we removed tuple splat feature. > > But right now can't see what we can do about this. > > (T1,T2) -> (T3,T4) really

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

> On 19 Apr 2016, at 17:24, Erica Sadun via swift-evolution > wrote: > >> > Short of a complete rethink of closure syntax, requiring parentheses there > would not improve the language in any measurable way. Does requiring the parentheses in (T1) -> T2 improve the language in any measurable

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

> On 19 Apr 2016, at 18:54, Haravikk wrote: > > I think your lists are incomplete. > > I’d say it’s on-topic, as removing variadic functions would eliminate the > problem entirely, so if it is considered a better alternative then there > would be no need to have an additional means of cal

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

> On 19 Apr 2016, at 17:51, Vladimir.S wrote: > > I suggest to look at the subject of this thread and initial proposal: I suggest to look at the post to which I was replying to find out why I said what I said. > > I.e. the question is *if we want/need to be able to pass array to existed >

  1   2   >