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

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

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

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.

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

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

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

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

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

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

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 >>

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

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 > >

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

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

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

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,

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

gt; wrote: >>> >>> >>>> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >>

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

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

> On 17 Jan 2017, at 11:28, Alex Blewitt <alb...@apple.com> wrote: > > >> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolut

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

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

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:

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.

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

d I think it works fine. > > -thislooksfun (tlf) > >> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution >>> <swift-ev

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. >

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

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

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

> On 20 Dec 2016, at 13:10, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > >> On Dec 20, 2016, at 4:32 AM, Jeremy Pereira via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> O

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:

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: > >

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. >

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

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

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

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,

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.

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

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

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.

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

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

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 >>

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

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

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") >>

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

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

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

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

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... > >

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)

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,

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

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 >

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

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

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

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

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

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

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

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. > >

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

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

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

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

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

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

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

+1,000,000 I hate the K 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

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

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

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

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 > >

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,

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 >>

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? >> >>

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

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

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: >>> >>>

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 list in > current Swift. Especially after we removed tuple splat feature. > > But right now can't see what we can do about this. > >

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

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

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

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

> On 19 Apr 2016, at 07:51, Haravikk via swift-evolution > wrote: > > > > I think the question really is whether not having to add square brackets is > really enough to justify a whole language feature? Basically you’ve got two > ways you could do this: > No,

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I think I would be -1 on this. The proposal is that there be two names, Self and self that refer to different objects but are differentiated only by the capitalisation of the first letter and these could be mixed in the same context. I think this would make code that uses both harder to read.

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> On 4 Apr 2016, at 18:18, Haravikk wrote: > >> >> On 4 Apr 2016, at 15:49, Jeremy Pereira >> wrote: >> >>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution >>> wrote: >>> >>> Although I use

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution > wrote: > > Although I use trailing closures a lot less now, I think I’m a +1 anyway for > consistency’s sake. > > I actually really like the idea of having trailing keywords in loops and if > statements,

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution > wrote: > >> In the low level world, there is no such thing as an invalid address; both >> 0x0 and ~0x0 are perfectly valid byte pointers. So using something else than >> 0x0 for Swift invalid

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 23 Mar 2016, at 15:50, Haravikk wrote: > >> >> >> True, but we could have argued the same about the `where` keyword and that >> is in existence. :-) > > Speaking of where, why wouldn’t you just do: > > for eachElement in theIntegerSequence where

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 23 Mar 2016, at 11:38, Brent Royal-Gordon wrote: > >> One advantage of the old C style for loop is that everything to do with loop >> control is in one place, usually on one line. There is currently no way of >> doing that for the (quite common) use case of

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 23 Mar 2016, at 10:40, Maximilian Hünenberger via swift-evolution > wrote: > > I totally agree with you that the for loop shouldn't be overloaded with > keywords. Although a "while" condition could be a reasonable addition since > the "breaking" condition is

Re: [swift-evolution] Support for newtype feature/typesafe calculations

I’m not saying your proposal would not be useful, but in the case of all of your examples, there are solutions that can be implemented now that might be better than just creating a new-type-but-exactly-the-same. > On 5 Jan 2016, at 16:11, Grzegorz Adam Hankiewicz via swift-evolution >

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

> On 5 Jan 2016, at 13:42, James Campbell wrote: > > So the [Int]() is shorthand for Array() Yes. In general, you can write [T] anywhere you can write Array and [U : V] anywhere you can write Dictionary. The are both syntactic sugar. > > On Tue, Jan 5, 2016 at

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

I don’t understand what the problem is > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution > wrote: > > See this code: > var distanceCache: [Int: Int] = Dictionary() > > It is very long and tedious to write especially if what I am storing

  1   2   >