Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

+1 I agree. Unwrapping in the functional signature is confusing for the user; many don’t realize that it puts the burden of checking on them. Non-optional function parameters make this explicit by preventing passing in Optional types, forcing the user to check, which they should be doing anyway.

Re: [swift-evolution] removing logical operators

I think keeping operators as actual operators is preferable. Having *some* but not all operators be keywords makes them “special” and unique, which they aren’t. On Wed, Jun 8, 2016 at 2:26 PM Saagar Jha wrote: > Well, IIRC Swift doesn’t allow operators that aren’t (math)

Re: [swift-evolution] Marking sort and sorted with rethrows

Might I add that leaving an array in an arbitrary and implementation-dependent state is also surprising to users as well as not very useful-to the user this is nothing more than a random permutation. On Mon, Jun 6, 2016 at 5:31 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Discussion: Why is "nil" not "none"

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C. On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > I guess for me it comes down to this: > > *Why were some and none chosen

Re: [swift-evolution] Discussion: Why is "nil" not "none"

That’s not quite what I meant. nil feels right to refer to an object-you can say “Foo is nil”, but you can’t really say that “Foo is none”, since while you can’t really use none as an adjective, as you can with nil. It’s really about what flows right-none is the opposite of some, but nil isn’t.

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Yes, that’s exactly my point. Force unwrapping optionals adds confusion for new users; all too often I see newcomers ending up with the assumption that the force unwrapping takes care of the check for them. On Thu, Jun 9, 2016 at 6:40 AM Spromicky via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Yes, that’s what I meant. Basically, I see stuff like this: func tripleForceUnwrapping(aString: String!) -> String { return String(byRepeatingString: aString, count: 3) } and later users get a crash with this: let possiblyNilString = someFunctionThatRetunsAnOptional()

Re: [swift-evolution] extend trailing closure rule

How about using a colon to separate it, to make `completion` look like an argument and to separate it from being a function? Something like this: UIView.animate(withDuration: 0.4) { // animations } completion: { finished in // completion } On Thu, Jun 9, 2016 at 1:06 AM Brent Royal-Gordon via

Re: [swift-evolution] Marking sort and sorted with rethrows

Exactly. While rethrows for sort make sense, since there is no user variable modification, sortInPlace either needs to revert the array (which is potentially expensive) or leave it in an arbitrary state, neither of which are good choices. I can’t seem to find any mutating function that rethrows,

Re: [swift-evolution] removing logical operators

Well, IIRC Swift doesn’t allow operators that aren’t (math) symbols, right? That might be the first barrier to clear. On Wed, Jun 8, 2016 at 2:24 PM Pranjal Satija via swift-evolution < swift-evolution@swift.org> wrote: > Hi there, > > I had an idea recently about the use of logical operators in

Re: [swift-evolution] Nil coalescing operator precedence

We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous because they are borrowed, in this case from math. The same thing applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from the C-type languages) and behaves likewise. There is no need for

Re: [swift-evolution] Nil coalescing operator precedence

Yes. They’re all operators we know about already, and the same argument applies. Just like you wouldn’t change + to have a higher precedence than *, bitwise operators already have their own, uniform precedences. I can’t see any reason not to have one, other than confusion from those who aren’t

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu wrote: > On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha wrote: > >> Yes. They’re all operators we know about already, and the same argument >> applies. Just like you wouldn’t change + to have a higher precedence

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

>> > >> > I would think this would not apply to public classes. >> > >> > There has also been discussion in the past about making final the >> default - I don’t remember if that ever resolved into some kind of >> consensus or not, though. >> > >

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

%, at least to me, suggests distant evaluation; i.e. parameter passing at the end. $ seems more like an in-place evaluation, like how bash does it. On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > That said, I think it's nice that \, #, $, and @

Re: [swift-evolution] Why hard-code octet-sized bytes?

I'm not quite sure what you mean. Swift has a type called Int8 that represents numbers from -128 to 127 using 8 bits. I don't see how this "excludes" computers. On Fri, Jun 17, 2016 at 13:01 Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > When I first looked into Swift, I

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

Correct me if I’m wrong, but if you’re writing some kind of framework and your class is not final but never subclassed, you wouldn’t want the warning, even if you’d like to allow users to subclass it? On Thu, Jun 16, 2016 at 9:02 AM Rehat Kathuria via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Alright, I’ve written it up a proposal; you can find it here . This is my first proposal (and anyways I’ve been told that I can be unclear), so if you guys see anything that should be changed feel free to let me know. Here it is

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

I believe that renaming of Apple’s frameworks is not in the scope of swift-evolution; I think you’re supposed to file a radar. On Mon, Jun 27, 2016 at 9:54 AM Jerome ALVES via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone, > > I can't find anything about Cocoa

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Seems fine to me. One addition though: some sort of round(withPrecision: Int) On Mon, Jun 27, 2016 at 12:23 Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 27, 2016, at 12:34 PM, Karl wrote: > > > On 27 Jun 2016, at 16:23, Stephen Canon

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

I don’t even see the purpose of allowing it in Objective-C code that doesn’t have an annotation. If you can check it against nil, just shadow an optional with a guard…it’s basically the same code and it’s a lot more clear on what’s happening. On Mon, Jun 27, 2016 at 11:12 AM Jean-Daniel Dupas via

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

On Mon, Jun 27, 2016 at 9:34 AM Karl via swift-evolution < swift-evolution@swift.org> wrote: > On 27 Jun 2016, at 16:23, Stephen Canon wrote: > > > On Jun 25, 2016, at 05:06, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > Proposal:

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

Any? or AnyObject?; have your dictionary be something like [String: AnyObject?]. On Sun, Jun 26, 2016 at 3:00 PM Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution < > swift-evolution@swift.org>: >

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

+1. I had this same problem when using map with enumerated-both $1 and $0.offset worked. I can see how this can be confusing to beginners. On Sat, Jun 25, 2016 at 8:36 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > I believe this should be done for Swift 3.0 release as

Re: [swift-evolution] Prohibit invisible characters in identifier names

The problem with depending on the IDE is that not everyone is using Xcode…or even a modern IDE. There are those that are using basic text editors, which must be considered as well. On Sun, Jun 26, 2016 at 9:25 PM Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun

Re: [swift-evolution] Prohibit invisible characters in identifier names

It’s leaving a lot of Linux users out to dry; a better option may be a sort of hybrid approach with a “middleman” tool that does the translation, which people could simply add as a build step if they needed translation. On Sun, Jun 26, 2016 at 11:08 PM Charlie Monroe

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

There’s remove, which is mutating in that it actually removes the elements from the target. removing, on the other hand is nonmutating and basically gives a copy and then removes from the copy. Saagar Jha > On Jul 25, 2016, at 21:21, Boris Wang via swift-evolution >

Re: [swift-evolution] Change subscripts to use colons

Feels like an abuse of subscripting IMHO. I'm fine with parametrized properties but the subscript doesn't quite fit in this case. Sent from my Apple Watch On Jul 11, 2016, at 23:24, David Hart via swift-evolution wrote: > How about a proposal for named subscripts?

Re: [swift-evolution] executing a string

Here’s how selectors in Swift work, based on this proposal. Swift’s selectors are a lot safer than Objective-C’s. > > > > > One

Re: [swift-evolution] [Draft] Fix a typo in two String methods

Well, yes, but hardly anyone calls it a “char array” unless they’re trying to emphasize the fact that it’s not being used as a String. Saagar Jha > On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution > wrote: > > On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun

Re: [swift-evolution] [Draft] Fix a typo in two String methods

Ahh…I agree in that case; something like `utf8Array` might be a better choice. Saagar Jha > On Jul 24, 2016, at 16:44, Xiaodi Wu wrote: > > On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha > wrote: > Well, yes, but hardly

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Ah, I understand now; that’s a good point. On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe wrote: > To use the parameters, the function would have to check for nil anyways, > right (or risk a crash at runtime)? If the parameter is changed from an IUO > to an Optional,

Re: [swift-evolution] [Proposal] autocreate parameter for optional values

If the compiler can figure out the type of the expression, you can use [:] in place of [NSObject: AnyObject], as below: let config = URLSessionConfiguration.default var headers = config.httpAdditionalHeaders ?? [:] headers["Some-Additional-Info"] = "1992-08-01" Saagar Jha > On Jul 28, 2016,

Re: [swift-evolution] End of source-breaking changes for Swift 3

The reason C-style for loops were removed were because most of the time they could be represented by Swift syntax. Have you taken a look at stride(from:to:by:)? Saagar Jha > On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi

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

Well, it depends on what kind of Math you’re trying to do. The Accelerate framework is available if you need performance. Saagar Jha > On Aug 1, 2016, at 18:01, Muse M via swift-evolution > wrote: > > Have always wonder why Maths in Swift is slower than C and Go,

Re: [swift-evolution] Proposal for swift build linux on Mac os x

Apple's bug reporter would be a better place. On Sat, Aug 13, 2016 at 16:16 Félix Cloutier wrote: > The swift-evolution mailing list is about the language itself, Xcode is > independent. I don't know where you could try to push that suggestion. > > > Félix > > Le 13

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

Saagar Jha > On Jul 20, 2016, at 18:02, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Nevin, > > extension String > { > var count: Int > { > get > { > return self.characters.count > } > } > >

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Oh, no, they’re just external function parameter names that I put to try to make it more clear. Looks like it didn’t really work :) Saagar Jha > On Jul 20, 2016, at 17:19, William Jon Shipley > wrote: > > Are “forceUnwrapping” and “withoutUnwrapping” special

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

gt;> >> >>> On Jul 5, 2016, at 13:30, Saagar Jha <saagarjh...@gmail.com >>> <mailto:saagarjh...@gmail.com>> wrote: >>> >>> Gave me a chuckle, but yeah, basically. >>> >>> On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley >>&

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Sorry for the last email…I didn’t see your response. I realize that disallowing IUOs in parameters (but not as properties) is inconsistent, but IUOs for properties make sense: they must be set during initialization, but sometimes this isn’t possible. IUOs make it possible to use the property

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

Sorry, my word choice here is poor. I meant that Swift Strings don’t really match up with character arrays in the usual sense; your “subscript” is O(n). Use a Range instead. Saagar Jha > On Jul 20, 2016, at 18:52, Ted F.A. van Gaalen wrote: > >> >> On 21.07.2016, at

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

To use the parameters, the function would have to check for nil anyways, right (or risk a crash at runtime)? If the parameter is changed from an IUO to an Optional, the check for nil simply becomes a shadowing with guard. Saagar Jha > On Jul 20, 2016, at 21:10, Chris Lattner

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

Was the problem with the ternary conditional operator that nothing could be found to replace it? That doesn't seem to be the issue here. On Mon, Jul 18, 2016 at 00:02 Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote: > I think this proposal is not > > ""better enough"

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

ar Jha > On Jul 5, 2016, at 13:30, Saagar Jha <saagarjh...@gmail.com> wrote: > > Gave me a chuckle, but yeah, basically. > > On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley > <w...@delicious-monster.com <mailto:w...@delicious-monster.com>> wrote: >

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

Here's a value type that uses custom equality (at least, I think so): String. Since it uses extended grapheme clusters, internally two Strings may be composed of different Unicode scalars, but if they create the same Characters they are considered to be equal. On Fri, Jul 15, 2016 at 09:12

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

Equatable, where the == operator is defined, will not let you compare two things of a different type. On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer wrote: > > > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution < > swift-evolution@swift.org>: > > > > >

Re: [swift-evolution] Addition of a standardError OutputStream

Thanks, I’ll write it up. > On Jul 11, 2016, at 11:20, Dave Abrahams via swift-evolution > wrote: > > > on Sun Jul 10 2016, Saagar Jha wrote: > >> What is the process for smaller issues like these? I’m guessing that >> this doesn’t need a

Re: [swift-evolution] Optional comparison operators

Correct me if I’m wrong, but wouldn’t you have to unwrap every comparison then? > On Jul 11, 2016, at 20:02, David Sweeris via swift-evolution > wrote: > > Why not have them return a `Bool?`? If both arguments are non-nil, it can > return the results of the

Re: [swift-evolution] adding Obj-C syntax to Swift?

Not quite sure what you mean. Swift is designed to be somewhat similar to C and C++; the “Rust-like” syntax is merely because Rust does it like C does. > On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution > wrote: > > Perhaps one of the most disliked aspects

Re: [swift-evolution] [Pitch] Require "infix" for infix operator function declarations

I wouldn’t go as far as to require it, but having it for optional use “for symmetry" seems fine to me. > On Jul 11, 2016, at 21:03, Jacob Bandes-Storch via swift-evolution > wrote: > > Currently, "infix" is not required/allowed on an operator function > definition,

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Yep, that’s what I meant. I should probably go back and re-write the proposal if it’s not clear. BTW, when does the window for proposals close? Is this in the scope for Swift 3? On Tue, Jun 28, 2016 at 9:54 PM David Waite wrote: > Hi Saagar, > > If I understand

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Gave me a chuckle, but yeah, basically. On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley < w...@delicious-monster.com> wrote: > On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution < > swift-evolution@swift.org> wrote: > > When I see an IUO property, I conside

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Sorry, but I’m going to use your use case as an example…hope you don’t take it personally :) Basically, your use of IUOs is exactly what I’m trying to avoid. IUOs may have their uses, but in my mind, they don’t (in my mind) indicate “This argument should not be nil on most occasions, but may be

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Most source breaking changes will be made in Swift 3. From now on code should be mostly backwards compatible. On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hi there > > From the perspective from many active programmers > that use

Re: [swift-evolution] Removing Variadic Parameters.

On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > 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

[swift-evolution] Addition of a standardError OutputStream

Currently, it’s rather annoying to print to standard error, requiring either something low-level like fputs. I was wondering if a standardError OutputStream could be added to the standard library, so we could write something like print(“foo”, ). -- -Saagar Jha

Re: [swift-evolution] [Pitch] Extending Swift Literals

Not completely sold on this one. First, the literal part is already pretty much implied, and I'd prefer dropping it as it feels too "heavyweight". The other, more serious issue was already partially touched upon by Xiaodi, that a lot of these are basically String representations. The Bezier

Re: [swift-evolution] Addition of a standardError OutputStream

rrStream() > func write(_ string: String) { fputs(string, stderr) } > } > > str.write(to: ) > > -- E > > >> On Jul 8, 2016, at 4:41 PM, Saagar Jha via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Now that I think of it, IUOs for function returns have a similar problem. When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”. That’s why IUOs make

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

+1 since it makes it easy to get the number of possible enum values, but I thought I'd tell you: there's no "Wind" type in Pokémon. It's "Flying". On Sun, Jul 3, 2016 at 18:36 Gabriel Lanata via swift-evolution < swift-evolution@swift.org> wrote: > Hello, this has been proposed multiple times

Re: [swift-evolution] for-else syntax

If you’re fine with a couple extra characters, you can use .isEmpty: for name in names { // do your thing } if names.isEmpty { // do whatever } It’s a bit more typing, but I feel it makes your intentions more clear. Saagar Jha > On Feb 1, 2017, at 8:48 AM, Chris Davis via

Re: [swift-evolution] Strings in Swift 4

it. I’m not sure if I’m getting my point across, please do let me know if you don’t quite get what I mean. Saagar Jha > On Jan 20, 2017, at 5:55 PM, Ben Cohen <ben_co...@apple.com> wrote: > > >> On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution >> <swift-evo

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

+1, provided these differences are ignored if the user manually builds a project. Hopefully this takes some of the load off of SourceKitService. On Wed, Jan 25, 2017 at 16:07 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Yes. It would stick once it appears (until it is

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

There's nothing wrong with fix-its and error messages, and indeed they can be quite helpful-the issue is that sometimes they show up when they really shouldn't, like in the middle of typing a line. Novices will then often stop and see what it's trying to say (wouldn't you trust a tool if it tells

Re: [swift-evolution] Strings in Swift 4

Found it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html Saagar Jha > On Jan 20, 2017, at 4:10 AM, Charlie Monroe via swift-evolution > wrote:

Re: [swift-evolution] [META] Gmane and Swift Evolution

I’ve submitted a pull that includes everything except for SE-0094, 0095, and 0110, which I wasn’t able to find. Saagar Jha > On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution > wrote: > > >> On Aug 2, 2016, at 9:22 AM, Ben Rimmington

Re: [swift-evolution] [Idea]Why not get dynamically named variables?

Have you thought about using a dictionary? You can fetch a recipe by looking up a key: let foods: [String: Foods] = [:] // fill it up appropriately with your own data let recipe = foods[TitleTextField.text].recipe Saagar Jha > On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution >

Re: [swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

This is expected behavior. The semicolon character is reserved in URLs, and it requires escaping if it is used. On Tue, Oct 25, 2016 at 12:05 Cao, Jiannan via swift-evolution < swift-evolution@swift.org> wrote: > > http://host/book;id=1/page;2/ > > this URL is a valid URL, but URLComponents will

Re: [swift-evolution] Import Conditionals

I believe there was a draft to merge all the "Libc" modules; let me see if I can find that. On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution < swift-evolution@swift.org> wrote: > *Description* > > In an effort to both (1) reduce boilerplate code, and (2) promote > cross-platform

Re: [swift-evolution] [Pitch] Numeric enum cases

I'm curious about the use case for this. For tuples it's a positional argument; how does this apply to enum cases which shouldn't depend on their order? On Tue, Nov 22, 2016 at 05:43 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Have we already discussed this somewhere?

Re: [swift-evolution] Tuples as RawRepresentable

If you're looking for a use case for tuple equality, I often pack a bunch of values in a tuple and check it with another, which makes it easy to compare a multiple values at once and perform something only if all of them are equal. On Sat, Oct 15, 2016 at 09:28 Haravikk via swift-evolution <

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

Did someone ask for more feedback? Overall, I'm pretty -1 on this proposal. I never really liked the fileprivate solution of scope being created to match (in my mind not quite related) file system/organizational boundaries of files–but it was the best compromise we could come up with at the

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

I’m along the lines of keeping the old behavior+warnings if “oldValue” is used for “newValue” and vice versa. Nonbreaking, and removes the issue of accidentally swapping the two. Saagar Jha > On Dec 3, 2016, at 7:33 PM, Derrick Ho via swift-evolution > wrote: >

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

oldValue is the value the property contained before didSet. self.value is the variable’s current value (i.e. newValue in willSet). Saagar Jha > On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution > wrote: > > -1. > > I always name parameters to code blocks

Re: [swift-evolution] [Idea] Extending syntax for `extension`

How exactly would this work? Would it restrict the extension to only the scope it’s defined in? Saagar Jha > On Dec 5, 2016, at 1:48 PM, Braeden Profile via swift-evolution > wrote: > > I really enjoy having the ability to write and nesting my code at the >

Re: [swift-evolution] [Out of scope][Discussion] Modernize MapKit functions for Swift API Design Guidelines

MapKit is not part of the Swift standard library; as such, it would probably be better if you used Apple’s Bug Reporter to let them know. Saagar Jha > On Jan 1, 2017, at 11:02 AM, Scott Gardner via swift-evolution > wrote: > > Hello Swift Community, and… > > if

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

t; >> On Jan 4, 2017, at 9:32 PM, Saagar Jha <saa...@saagarjha.com >> <mailto:saa...@saagarjha.com>> wrote: >> >> >> >> Saagar Jha >> >> >> >>> On Jan 4, 2017, at 8:35 PM, Douglas Gregor <dgre...@apple.com &g

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

Check out this thread –it’s very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to this as well as the ability to use multiple trailing closures like so: animate(identifier: “”, duration: 0,

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

Saagar Jha > On Jan 4, 2017, at 8:35 PM, Douglas Gregor <dgre...@apple.com> wrote: > > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Check out this thr

Re: [swift-evolution] Support for assertions/preconditions that sometimes fail.

Why not just add a // TODO or // FIXME comment? Saagar Jha > On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution > wrote: > > It’s quite common for an assertion/precondition that you thought should hold > actually does not yet there is no bug. In that

Re: [swift-evolution] [Pitch] Adding safety to arrays

Dynamic programming comes to mind. Saagar Jha > On Apr 16, 2017, at 19:33, Riley Testut wrote: > > My bad, should have phrased my response better :^) > > Under what circumstances would you need to be able to assign elements in an > array out of order, while also

Re: [swift-evolution] [Pitch] Adding safety to arrays

A Dictionary uses a lot more space than an Array, though, and allow for bogus keys like “-1”, etc. Saagar Jha > On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution > wrote: > >> Personally, the only valid use-case I can think of is when you want to >>

Re: [swift-evolution] class indent in swift, history?

I believe the indentation is more a signal for a new scope than curly braces. Swift doesn’t indent its switch cases since they’re a part of the same scope, while nested types and methods are a new scope. Saagar Jha > On Mar 7, 2017, at 05:38, Derrick Ho via swift-evolution >

Re: [swift-evolution] Low efficiency multidimensional array problem

It might be helpful if you showed a bit more of the code you’re working on, so that we can better see what you’re trying to do. Is there any operation in particular that is slow? Also, CC’ing swift-users since I think it belongs there. Saagar Jha > On Apr 18, 2017, at 22:57, Hbucius Smith via

Re: [swift-evolution] Xcode Fix-It action for returning closures

You should probably file a Radar for this, since Xcode isn’t part of the Swift project. Saagar Jha > On Jul 13, 2017, at 19:46, iCloud via swift-evolution > wrote: > > Hi Swift community, > > I was wondering if we have considered adding support for providing Xcode

Re: [swift-evolution] pitch: Unified libc import (again)

Just thought I’d link the previous thread on this topic: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023927.html . I had promised to write a proposal for it back then, but never got

Re: [swift-evolution] [Idea] `enum` case count feature

Not Nicholas, but I thought I’d share one of my use cases. I use a enum (with a Int raw value) for sections in a table view, so whenever the table view asks for the number of rows I pass in the number of cases. Currently, I’m doing something like this: enum Sections: Int { case

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

It reads better and feels more natural. In my mind, it’s similar to the difference between ["1", "2", "3"].flatMap { Double($0) } and ["1", "2", "3"].flatMap(Double.init) Saagar Jha > On Jun 9, 2017, at 16:06, Max Moiseev via swift-evolution > wrote: > > Sorry.

Re: [swift-evolution] [SR-3281] Update swift man page

Looks great…at least, it’s much better than the old one. One thing that stuck out was the “by Apple Inc.” in the synopsis. I think you should ask one of the Core Team members for advice on this, but to me it 1. reduces the impact of outside collaborators on the language and 2. makes it appear

Re: [swift-evolution] optional variable with ternary operator

Well, you’re not allowed to compare optionals any more. You can try binding the value to an Int, so that it’s not an optional anymore: if let number = number { let result = number > 0 ? 1 : 2 } Either way, you’ll have to decide what you think should happen when number is nil. Saagar

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

Saagar Jha > On Aug 30, 2017, at 16:42, Robert Bennett via swift-evolution > wrote: > > But countless editors have popped up since vi(m) first appeared. If anything, > this is a testament to the fact that old, “crusty” technology can remain > relevant forever,

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Sent from my iPhone > On Sep 25, 2017, at 22:16, Jonathan Hull via swift-evolution > wrote: > > As he says, it is an in-place equivalent of filter, so the use-cases would be > similar. I could see this being extremely useful. Off the top of my head: > >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

(Disclaimer: I’m no expert in this, and I know there are people in this list that are, so if there’s anything wrong please feel free to step in and correct me) As far as I’m aware, Apple’s frameworks check which version of the framework you linked with at runtime (for UIKit, I believe this

Re: [swift-evolution] Renaming SwiftObject

Just my 2¢, from the point of view of someone runs into SwiftObject frequently: I’d really appreciate it if this class had “Swift” in it’s name. At first glance, it’s name in mangled form (“_TtCs7_Object”) gives no indication as to where it’s from. Obviously it’s not a “pure” Objective-C

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Well, in my experience performance issues tend to come not from trying to display a single object, but when you have an aggregation of many objects. For example, displaying one Int is pretty lightweight, as is an [Int] with a handful of elements, but displaying an [Int] with million elements is

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

Not a floating point expert, but are you sure this works? I have a feeling this would lead to a distribution that’s not uniform. Saagar Jha > On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution > wrote: > > On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Saagar Jha > On Jan 10, 2018, at 14:10, Connor Wakamo wrote: > >> On Jan 10, 2018, at 12:39 PM, Saagar Jha > > wrote: >> >> Well, in my experience performance issues tend to come not from trying to >> display a single

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

Which begs the question: why would you want to do something like this? Creating a “random” Double from its full range of values is an odd thing to do, and the fact that it is non-uniform and has irregularities like infinity and signed zeros makes it likely that any such usage is probably done

Re: [swift-evolution] Renaming SwiftObject

Well, there’s always the option of Swift._NonObjcSwiftObject…but to be honest what this class looks like from the Swift side is much less of a concern to me. Getting “Swift” in the mangled name is probably good enough. Saagar Jha > On Jan 8, 2018, at 15:00, Greg Parker

Re: [swift-evolution] Protocol conformance error

} > > class M: C { >func test() -> B { > fatalError("just a stub") >} > } > > It gives the error “inferred type 'B' (by matching requirement 'test()') is > invalid: does not conform to ‘A’” even though B does conform to A.

  1   2   >