Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Forgive me for creating a new thread, I don't know how to reply to an archived discussion (I just registered to the mailing-list). > On *Wed Jun 15 15:09:52 CDT 2016, **Matthew Johnson* matthew at anandabits.com wrote: > There are two reasonable options here: > > 1. Allow both `private` and `

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > Sure, but `mappingAndFlattening(to:)` would have brevity issues as well. My point was that if you want to transform sin() -> sine() you'd be pretty much forced to also do atanh() -> hyperbolicArcTangent(). However the proposed transformation is for flatMap() to flatMapped(), which doesn't hav

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

Old old old architectures. We're talking Multics days. ~Robert Widmann 2016/06/17 21:35、David Sweeris via swift-evolution のメッセージ: > IIRC, a bunch of Ye Olde systems used 6-bit bytes. And I think 36-bit ints > were used in a few architectures, but don't quote me on that. > > - Dave Sweeris >

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

IIRC, a bunch of Ye Olde systems used 6-bit bytes. And I think 36-bit ints were used in a few architectures, but don't quote me on that. - Dave Sweeris > On Jun 17, 2016, at 22:48, Félix Cloutier via swift-evolution > wrote: > > Out of curiosity, can you name an architecture that doesn't use

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

Out of curiosity, can you name an architecture that doesn't use 8-bit bytes? Félix > Le 17 juin 2016 à 13:01:33, Daryle Walker via swift-evolution > a écrit : > > When I first looked into Swift, I noticed that the base type was called > “UInt8” (and “Int8”) and not something like “Byte.” I k

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

You raise an interesting point. To explore this further: we could definitely just lower a lot of it to the appropriate integer-width arithmetic in LLVM. I suspect the limitations of the standard library implementation you bring up exist because "nonstandard" types such as these don't show up w

[swift-evolution] Fixing modules that contain a type with the same name

Hello all, I recently ran into a bug that leaves me unable to fully-qualify the name of a type. If you import a module named Foo that also contains a type named Foo, attempts to fully-qualify any name in the Foo module will instead attempt to find so

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> – What sin(x) should do is unambiguous, unlike array.filter { ... }. A decent argument label, like `including` or even `to`, would fix the name `filter`. And as I said, if we feel `filter` is unsalvageable, the alternate Smalltalk-lineage `select` is clearer. > – There's very significant brev

[swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

More generally, this is the issue of whether the automatic discardability of Void should be extended to Optional. This could also apply to the result of optional chaining. EG: observer?.update() //returns ()? compared to: if let unwrapped = observer { unwrapped.update() //returns () } Sinc

[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

I heard that this has been brought up before, but what if we give all non-mutating methods the same name as their mutating counterparts? The compiler can just pick the right one based on whether an assignment is taking place or not. Here are the advantages I can think of: - it would end this de

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, David Waite wrote: > I’ve always considered the term of art argument to be at least partially a > red herring. > > These methods are difficult because you don’t have guarantees of > non-mutability until you get to Collection - on Sequence, a dropFirst > method may mean that

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

on Thu Jun 16 2016, David Waite wrote: > -1, for the same reasons stated on the thread. These are neither > guaranteed to be mutating or non-mutating until you get to Collection. > > Changing map() to mapped() would be lying to the developer some of the > time about the mutability of the interfa

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

> On Jun 17, 2016, at 3:07 PM, Xiaodi Wu wrote: > > Right. I don't think there's any plan currently to allow enum case > declarations of reserved keywords without backticks. The reasoning, IIUC, was > that use sites were far more common and in that context cases could be > distinguished by the

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Right. I don't think there's any plan currently to allow enum case declarations of reserved keywords without backticks. The reasoning, IIUC, was that use sites were far more common and in that context cases could be distinguished by the leading dot. By contrast, declarations are made only once. FW

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] [Pitch] Allow use of the name "default" for enum cases and function names

It looks like it’s not-quite-done for enum cases in Xcode 8: You can’t declare an enum with a case named “default” without escaping the name. However, it looks like you can refer to an enum case named “default” using simply “.default”, which I didn’t realize. (I had mistakenly assumed the escapi

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Thanks to you (and Ben Remmington on another thread) for pointing that out—it's been a while since I read that doc so I've forgotten specific cases :) I'm lukewarm about C family precedent necessarily constraining us in a world where one compiler diagnostic can teach developers the Swift way of do

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Replacing default with case _ is a commonly rejected proposal, and I do believe it's been discussed since the lowercasing of enum cases. On Fri, Jun 17, 2016 at 15:55 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > Agreed, it sounds like default should be treated as a cont

Re: [swift-evolution] [Pitch] Allow use of the name

Tony Allevato wrote: > It never even occurred to me that "case _:" would work as a replacement for > default, but it does even today—and now that I've seen it, it makes total > sense. I could definitely get behind a proposal to remove "default" as a > keyword from the language entirely in favor of

Re: [swift-evolution] Enhanced existential types proposal discussion

added a few comments to https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 to clarify the rational. it is by no mean the only way or a good way, but IMO there are far worse ways to do the same. > On Jun 6, 2016, at 1:20 AM, Douglas Gregor via swift-evolution > wrote: > >

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Agreed, it sounds like default should be treated as a contextual keyword in this case. It never even occurred to me that "case _:" would work as a replacement for default, but it does even today—and now that I've seen it, it makes total sense. I could definitely get behind a proposal to remove "de

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Isn't this already done, at least for enum cases? I'm pretty sure I've seen discussion of this before, and I thought it might've gotten implemented. On Fri, Jun 17, 2016 at 1:45 PM E. Maloney via swift-evolution < swift-evolution@swift.org> wrote: > While upgrading to Swift 3, I noticed that I had

[swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

While upgrading to Swift 3, I noticed that I had a few enums with cases named .Default that, after being converted to lowercase, now need to be rendered using the ugly .`default` notation. I also noticed something similar while reading the docs for NotificationCenter (the NSNotificationCenter r

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 17, 2016, at 7:04 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jun 16 2016, Thorsten Seitz > wrote: > >>> Am 13.06.2016 um 04:04 schrieb Dave Abrahams : >>> >>> >>> on Fri Jun 10 2016, Thorsten Seitz wrote: >>> > Am 09.06.2016 u

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

When I first looked into Swift, I noticed that the base type was called “UInt8” (and “Int8”) and not something like “Byte.” I know modern computers have followed the bog standard 8/16/32(/64) architecture for decades, but why hard code it into the language/library? Why should 36-bit processors

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

+1 for consistency. —A > On Jun 17, 2016, at 12:04 PM, Patrick Pijnappel via swift-evolution > wrote: > > You could make the exact same arguments about `sin`. > > – What sin(x) should do is unambiguous, unlike array.filter { ... }. > – There's very significant brevity issues here, e.g. hyper

Re: [swift-evolution] Permutations

On Jun 17, 2016, at 10:42 AM, Daryle Walker via swift-evolution wrote: > > I’ve seen the WWDC 2016 Keynote and State of the Platforms videos. I haven’t > seen any others so I don’t spoil myself before typing my ideas down. > Apologies if this has already been covered. > > I saw that the “Pe

[swift-evolution] generic typealias inside generic type

Please consider this code: struct Foo { typealias Group = (key:Key, group:[Value]) func bar(u: U, v: V) -> Foo> { return Foo>() } } It will not compile: cannot specialize non-generic type '(key: Key, group: [Value])' But this will work as expected: typealias Group = (key:K

Re: [swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

> Unlike its companion collections like NSArray, NSDictionary, and NSSet, > NSOrdered is still a class rather than a struct and has a subclass that is > still NSMutableOrderedSet. This should probably receive the same treatment as > the other classes Swift Evolution proposal SE-0069 "Mutability

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

This seems like a better job for an external linter tool or extended static analyzer. On 6/16/16, 02:55, "swift-evolution-boun...@swift.org on behalf of Rehat Kathuria via swift-evolution" wrote: >I¹d like the compiler to present a warning when a class not declared as >final is never subclassed.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Thu Jun 16 2016, Thorsten Seitz wrote: >> Am 13.06.2016 um 04:04 schrieb Dave Abrahams : >> >> >> on Fri Jun 10 2016, Thorsten Seitz wrote: >> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution : > Am 09.06.2016 um 18:49 schrieb Dave Abrahams via

[swift-evolution] [Pitch] String prefix operator

Motivational example: var urlString = self.urlString if urlString.hasPrefix("//") { urlString = "http:" + urlString // urlString needs to be typed twice } While there is currently an easy way to append string using +=, there is no shortcut for prefixing a string. What I propose is adding

[swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

Hello everyone, Unlike its companion collections like NSArray, NSDictionary, and NSSet, NSOrdered is still a class rather than a struct and has a subclass that is still NSMutableOrderedSet. This should probably receive the same treatment as the other classes, namely: - Use value semantic - Use

Re: [swift-evolution] `once` keyword for use with loops

Aren’t there already methods that stick elements between others (and only between, neither before the first nor after the last)? //= fun toCSV2(values: [CustomStringConvertible]) -> String { return values.map { $0.description }.joinWithSeparator(“, “) } //= — Daryle Walker Mac, Inte

[swift-evolution] Permutations

I’ve seen the WWDC 2016 Keynote and State of the Platforms videos. I haven’t seen any others so I don’t spoil myself before typing my ideas down. Apologies if this has already been covered. I saw that the “PermutationGenerator” type is being retired in Swift 3. It inspired me to see how I ca

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

> On Jun 16, 2016, at 11:32 AM, Charlie Monroe via swift-evolution > wrote: > > Hard to say without full code, but the following code compiles just fine in > Xcode 8: > > class FloorPlatonicGeometryAndMaterial { > init(modelDirectory: NSURL) throws { > /// ... > } >

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > You could make the exact same arguments about `sin`. – What sin(x) should do is unambiguous, unlike array.filter { ... }. – There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh(). – The relevant metric of the strength of a term of art would be for how many users

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On Jun 16, 2016, at 9:46 AM, Thorsten Seitz via swift-evolution > wrote: > >> >> Am 16.06.2016 um 17:36 schrieb Paul Cantrell > >: >> >>> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Protoc

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

On 17.06.2016 15:58, Patrick Pijnappel wrote: I suggest to leave map+flatMap+reduce as-is as true terms-of-art Question still stands, what benefits do we gain from using the /exact/ terms that are not present in the slightly modified ones? I don't know :-) I just see that many against re

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> Question still stands, what benefits do we gain from using the exact terms > that are not present in the slightly modified ones? Instant, unambiguous recognition. Look. You could make the exact same arguments about `sin`. We could create a `sine()` method on FloatingPoint and install a dummy

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > I suggest to leave map+flatMap+reduce as-is as true terms-of-art Question still stands, what benefits do we gain from using the *exact* terms that are not present in the slightly modified ones? On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel < patrickpijnap...@gmail.com> wrote: > `map`,

Re: [swift-evolution] Bitshift operators

> **In initializers that perform full-width type conversions, omit the > first argument label**, e.g. `Int64(someUInt32)` OptionSet could add `init(_ rawValue: RawValue)` to reduce boilerplate: struct FooOptions: Op

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

+1 for naming consistency. Opposite to many other modern languages where these methods/funcs exists, Swift choose another way(inverted) to name func/methods - "normal" name for mutating methods and with -ing/-ed suffix for non-mutating. But as a compromise, I suggest to leave map+flatMap+reduc

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> > `map`, `filter`, and `reduce` are *the* higher-order functions. Almost > anything with any kind of block/lambda/closure feature supports them (I'm > giving the side-eye to Foundation here), and all three names are backed by > *very* strong conventions > If `map`, `filter`, and `reduce` are n

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

On 17.06.2016 0:07, Gmail via swift-evolution wrote: -0.5 I find the "term of art" argument strong in this case, especially for map/filter/reduce. These functions are different than for example `sort` because there can’t be a general mutating method of `map`. A variable of type `[A]` can’t be m

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote: -1, for the same reasons stated on the thread. These are neither guaranteed to be mutating or non-mutating until you get to Collection. Changing map() to mapped() would be lying to the developer some of the time abou

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Support Patrick's opinion. It seems for me that 'map'(+'flatMap') and 'reduce' could be leaved as-is as *true* terms of art. Nothing else should be added to these exception group. Also please consider this code: let foo = elements .map {..} .reduce() {...} .filter {} .sorted {} why is so: "filt

Re: [swift-evolution] Removal of dispatch_once() in Swift 3?

Ben Rimmington wrote: > William Shipley wrote: > > > I may be missing something, but I don’t understand how to get the behavior > > of dispatch_once() without a bunch more code in cases in which I was using > > it to initialize “lazy-ish" instance variables. > > In Objective-C, the `dispatch_once_

Re: [swift-evolution] [Pitch] String prefix operator

> urlString =+ "http:" > > Would anyone else find it useful? Well, I mean, maybe sometimes, in terms of expressiveness. But there are a few problems: * It's kind of misleading, because this is very likely to be *far* less efficient than `+=`. Rather than appending to the existing string buffer

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

> On Jun 17, 2016, at 1:20 PM, Brent Royal-Gordon > wrote: > >> The required _ = try? on what used to be a BOOL result in ObjC is incredibly >> annoying, mostly with NSXML* classes on OS X where you really don't care >> about the error 99% of the time, but care just about the result >> (node

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

> On 17 Jun 2016, at 8:21 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> map => mapped >> flatMap => flatMapped >> filter=> filtered >> reduce=> reduced > > You posted before I finished responding to this on the other thread, so I > guess I'll do it here. > > You're

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

> The required _ = try? on what used to be a BOOL result in ObjC is incredibly > annoying, mostly with NSXML* classes on OS X where you really don't care > about the error 99% of the time, but care just about the result > (nodesForXPath, etc). Are you in control of the XPath strings? If so, you

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

+1. The required _ = try? on what used to be a BOOL result in ObjC is incredibly annoying, mostly with NSXML* classes on OS X where you really don't care about the error 99% of the time, but care just about the result (nodesForXPath, etc). > On Jun 17, 2016, at 1:04 PM, Jonathan Cotton via swif

[swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

I propose that the compiler warnings for unused results are removed from try? if the statement being ‘tried’ does not return itself. This is inline with how try works and although try? does have a possible return value itself (nil) the warning isn’t adding/helping any if the result is either goi

[swift-evolution] [Discussion] access control modifier inconsistency

I’ve spotted some inconsistency on access control modifier I’d like to discuss in this thread (the behavior is not groundbreaking but inconsistent from readers and developers view perspective). Why are extensions not marked as public in public apis when the module is imported? Any type members