Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Thu, Jul 21, 2016 at 1:40 AM, Robert Widmann wrote: > > On Jul 20, 2016, at 10:04 PM, Xiaodi Wu wrote: > > On Wed, Jul 20, 2016 at 10:33 PM, Robert Widmann > wrote: > >> >> >> ~Robert Widmann >> >> 2016/07/20 19:01、Xiaodi Wu via swift-evolution >> のメッセージ: >> >> On Wed, Jul 20, 2016 at 8:10

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution > wrote: > > The problem is that by specifying "import Foo using (Baz)", I get nothing > else from Foo. If I only want to exclude one conflicting name, I would have: > >> import Foo >> import Bar hiding (Baz) > > In case of a

Re: [swift-evolution] Tuple

Ok, I created an issue: https://bugs.swift.org/browse/SR-2135 lg, Fabian Ehrentraud Mobile Developer willhaben internet service GmbH & Co KG Landstraßer Hauptstraße 97-101, 1030 Wien M +43 699 1003 1604 DVR 4011331 Firmenbuch Nr. FN 271792 w Gerichtsstand Han

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 10:04 PM, Xiaodi Wu wrote: > > On Wed, Jul 20, 2016 at 10:33 PM, Robert Widmann > wrote: > > > ~Robert Widmann > > 2016/07/20 19:01、Xiaodi Wu via swift-evolution > のメッセージ: > >> On Wed, Jul 20, 2016 at

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

This approach in no way rules out that direction and the syntax here was built with a module system in mind. Agda modules admit the kind of abstraction you’re looking for, but they call them Parameterized Modules and they take after Coq’s sections rather than SML’s module functors. I can assur

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

This is the best argument: lets not make the behaviour surprising to people coming from other languages out there. > On 21 Jul 2016, at 04:57, Jaden Geller via swift-evolution > wrote: > > This discussion is getting out of control. Both of these functions have > mathematical precedent as well

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> Brent Royal-Gordon: If, as seems likely for lens support, we eventually > supported inout functions: > > func foo(x: Int) -> inout String { > get { return myStr } > set { myStr = newValue } > } > > Would you feel differently about having `:` on subscript

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Thanks for writing these up, I found them clear and easy to read. While I don’t know the precise inspirations, both of these drafts seem more or less in line with the sorts of modules and importing that’s found in Haskell. I’d much prefer these facilities not be added to Swift. I would much rath

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 10:33 PM, Robert Widmann wrote: > > > ~Robert Widmann > > 2016/07/20 19:01、Xiaodi Wu via swift-evolution > のメッセージ: > > On Wed, Jul 20, 2016 at 8:10 PM, Robert Widmann > wrote: > >> >> On Jul 20, 2016, at 5:47 PM, Xiaodi Wu wrote: >> >> On Wed, Jul 20, 2016 at 6:30 PM, R

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. And what if the overridden method returns "T!"? It would become T? i

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

The problem is that by specifying "import Foo using (Baz)", I get nothing else from Foo. If I only want to exclude one conflicting name, I would have: > import Foo > import Bar hiding (Baz) In case of a conflict, my "internal monologue" is more like "take Baz from Foo" than "don't take Baz from

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 03:15, Saagar Jha >

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

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

> On Jul 20, 2016, at 5:24 PM, Saagar Jha wrote: > > 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 th

[swift-evolution] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

Hello Swift community, The review of "SE-0127: Cleaning up stdlib Pointer and Buffer Routines" begins now and runs through July 24. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md Reviews are an import

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

I think there’s some value to point out these counterparts even when we are trying to do something new. Specifically, how much would we have lost, if we didn’t accept the proposal? By looking at these examples, one might conclude “not much”. Also, it’s not the main reason I’m against this chang

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

~Robert Widmann 2016/07/20 20:07、Félix Cloutier via swift-evolution のメッセージ: > My understanding is that we want "using" and "hiding" because we want the > ability to either take just a few things OR leave out just a few things. With > a unified "import Foo (A = B, C = D, E = _) syntax, we on

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

~Robert Widmann 2016/07/20 19:01、Xiaodi Wu via swift-evolution のメッセージ: >>> On Wed, Jul 20, 2016 at 8:10 PM, Robert Widmann wrote: >>> On Jul 20, 2016, at 5:47 PM, Xiaodi Wu wrote: On Wed, Jul 20, 2016 at 6:30 PM, Robert Widmann wrote: “The Phase Distinction” is a sema

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

My understanding is that we want "using" and "hiding" because we want the ability to either take just a few things OR leave out just a few things. With a unified "import Foo (A = B, C = D, E = _) syntax, we only get the ability to take a few things AND hide a few things. I've never really been

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

I don't disagree with discussing other languages. I'm just pointing out that C++ doesn't have a notion of computed properties, so subscript couldn't pretend to be a computed property even if it'd like! Python does have a similar construct, but it's computed properties *also* look like functions

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

> I’d say, please try to find possible empty strings > that might perhaps be embedded e.g. in the string below: > > “Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42” There are many empty strings in that string. In fact, there are infinite empty strings between each character, be

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

This discussion is getting out of control. Both of these functions have mathematical precedent as well as consistent behaviors in other languages. Observe: Python: `"hello world".startswith("")` => `True` Java: `"hello world".startsWith("")` => `true` JavaScript: `"hello world".startsWith("")` =

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

It's part of the review template :) Daniel Duan Sent from my iPhone > On Jul 20, 2016, at 7:23 PM, Jaden Geller wrote: > >> Python's __getitem__() method, C++'s [] operator are some analogous >> examples. Non -of them pretend not to be a function. The users of these >> features appear to be s

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> Python's __getitem__() method, C++'s [] operator are some analogous examples. > Non -of them pretend not to be a function. The users of these features appear > to be satisfied by the decision. This seems irrelevant since Swift already has computed properties which pretend not to be a function

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

* What is your evaluation of the proposal? -1. To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of subscribe(get

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 8:10 PM, Robert Widmann wrote: > > On Jul 20, 2016, at 5:47 PM, Xiaodi Wu wrote: > > On Wed, Jul 20, 2016 at 6:30 PM, Robert Widmann > wrote: > >> “The Phase Distinction” is a semantic one, not one built into the import >> system itself. >> > > > I understand. To rephras

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 5:56 PM, Robert Widmann wrote: > > Max and I had a discussion about how overloading would work here. We came to > the conclusion that we probably don’t need an “overload picker” because it > defeats the point of an overloaded name in the first place. > > As for the ex

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

Sent from my iPad On Jul 20, 2016, at 8:47 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution >> wrote: >> >> However, the current notation of -> Type being used to declare an input >> parameter to set {} just strikes me as

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

> On 21.07.2016, at 03:15, Saagar Jha wrote: > > > Saagar Jha > > > >> On Jul 20, 2016, at 18:02, Ted F.A. van Gaalen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Nevin, >> >> extension String >> { >> var count: Int >> { >> get >> {

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

Don’t Panic ! At the risk of seeing things in a somewhat trivial perspective, combined with an almost complete absence of abstraction: Note that to relatively simple persons like me: String instances are just rows of characters (when not empty, of course) There are only two kinds of Strings:

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution > wrote: > > However, the current notation of -> Type being used to declare an input > parameter to set {} just strikes me as weird and wrong. The symbol -> means > “returns a” or “yields”. Since we’re declaring a type that might

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

> On Jul 20, 2016, at 3:26 PM, Karl wrote: > >> Sealed is *non-committal*. It makes no promises to wider scopes about >> whether there are other subclasses/overrides; it merely states that code >> outside the module may not subclass/override. `final`, on the other hand, is >> an *affirmative*

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 > } > } > > // Sigh... String subscripto

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 5:47 PM, Xiaodi Wu wrote: > > On Wed, Jul 20, 2016 at 6:30 PM, Robert Widmann > wrote: > “The Phase Distinction” is a semantic one, not one built into the import > system itself. > > > I understand. To rephrase my question: why introduce this

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

Hi Nevin, extension String { var count: Int { get { return self.characters.count } } // Sigh... String subscriptors should be already builtin in the String subscript (idx: Int) -> String { get {

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Max and I had a discussion about how overloading would work here. We came to the conclusion that we probably don’t need an “overload picker” because it defeats the point of an overloaded name in the first place. As for the extension members, the current qualified import mechanism doesn’t all

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

One thing to consider is that Swift has compound names, and also extension members, which are modularized but also scoped to the extended nominal type or protocol. Extension method collisions are a non-theoretical issue. Whatever bikeshed we pick, we'll want a syntax able to support something li

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 6:30 PM, Robert Widmann wrote: > “The Phase Distinction” is a semantic one, not one built into the import > system itself. > I understand. To rephrase my question: why introduce this semantic distinction to Swift? What I meant is that even the system I’m modeling this

[swift-evolution] [Returned for revision #2] SE-0117: Default classes to be non-subclassable publicly

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md The second review of "SE-0117: Default classes to be non-subclassable publicly" ran from July 15…22. The proposal has been *returned for revision*, again. :-) As with the fir

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Great! I have an attempted implementation here. Would appreciate if someone can kick off a CI build/test. https://github.com/apple/swift/pull/3637 On Wed, Jul 20, 2016 at 5:38 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swi

[swift-evolution] [Rejected] SE-0123: Disallow coercion to optionals in operator arguments

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md The review of "SE-0123: Disallow coercion to optionals in operator arguments" ran from July 12...19. The proposal has been *rejected*. The majority of

[swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md The review of "SE-0121: Remove Optional Comparison Operators" ran from Active review July 12...19. The proposal has been *accepted*. Feedback has been universally positive

[swift-evolution] [Accepted] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md The second review of "SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct" ran from Active review July 12...19. The proposal has been *accepted*,

[swift-evolution] [Accepted] SE-0116: Import Objective-C id as Swift Any type

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md The review of "SE-0116: Import Objective-C id as Swift Any type" ran from Active review July 5...11. The proposal has been *accepted*, pending more implementation experience: This proposal was very

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

+1 to Karl's suggestion I've come around to the idea of not allowing subclassing by default (well, 50/50) because I rarely see final used in swift code (read: it's underused). However, I think the special casing of 3rd party libraries is weird. Let's assume this is true: "It's really bad for deve

[swift-evolution] [Accepted] SE-0120: Revise partition Method Signature

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md The review of "SE-0120: Revise partition Method Signature" ran from Active review July 12…19. The proposal has been *accepted*: There was very sparse commentary, and all of it was posi

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 ju

[swift-evolution] [Accepted] SE-0124: Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a bitPattern: label

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md The review of "SE-0124: Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a bitPattern: label" ran from Active review July 15…20. The p

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 keywords here or are > they jus

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

I know and I want to point out that you said value type don't have any thread safety issues is wrong. Johannes Neubauer 於 2016年7月20日星期三 寫道： > Dear Susan, > > > Am 20.07.2016 um 14:14 schrieb Susan Cheng >: > > > > I forgot to reply, a shared value type can capture by multiple closures. > > > >

[swift-evolution] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

Hello Swift community, The review of "SE-0126: Refactor Metatypes, repurpose T.self and Mirror" begins now and runs through July 24. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md

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

Are “forceUnwrapping” and “withoutUnwrapping” special keywords here or are they just there to try to explain what you’re doing? Because I was very confused by them. -Wil___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/

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

(Comments inline) Saagar Jha > On Jul 20, 2016, at 16:47, Saagar Jha wrote: > > > > On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner > wrote: > On Jul 19, 2016, at 3:46 PM, Saagar Jha > wrote: >> >> I have updated the proposal here >

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

> On Jul 20, 2016, at 12:52 PM, Chris Lattner wrote: > > On Jul 19, 2016, at 3:46 PM, Saagar Jha > wrote: >> >> I have updated the proposal here >> . Since >> this is a potentially a source brea

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

> limiting “open” to public classes only lets you be sloppy inside your own module. I don't find that idea bad actually. In the similar vein one can say "it's ok to be sloppy with local variable names, it's not ok to be sloppy with instance variable names". Again, tradeoffs. You can require tha

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I am confused as to why you think this would necessitate multiple phases of import logic to implement. We already have code that essentially does this baked into the code completion system.

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

“The Phase Distinction” is a semantic one, not one built into the import system itself. What I meant is that even the system I’m modeling this on makes a distinction between import directives that actually expose identifiers to modules and import directives that modify identifiers that are alre

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

> On Jul 20, 2016, at 3:30 PM, Dave Abrahams wrote: > > > on Wed Jul 20 2016, Dave Abrahams wrote: > >> on Wed Jul 20 2016, Jonathan Hull wrote: >> >>> Basically, I added back in a super-minimal protocol to fill the >>> structural gap left by Sequence. I call it “IteratorProvider”

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

To the question of whether any given string has the empty string as prefix: yes it does. This is a correct answer, and returning true is a correct behaviour. To the question of how many times the empty string occurs in a string: yes, this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" +

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 4:57 PM, Robert Widmann wrote: > > On Jul 20, 2016, at 2:52 PM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jul 20, 2016, at 2:35 PM, Xiaodi Wu wrote: > > > > On Wed, Jul 20, 2016 at 4:24 PM, Robert Widmann > wrote: > >> >> On Jul 20

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Regards (From mobile) > On Jul 21, 2016, at 12:38 AM, Robert Widmann wrote: > > As cannot (and should not) hide substructures and can be added later if you > so desire. > > >> On Jul 20, 2016, at 3:36 PM, L. Mihalkovic >> wrote: >> >> Hiding is not necessary if you import into a pseudo con

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 20 Jul 2016, at 21:25, Leonardo Pessoa wrote: > > I'm strongly opposed to this too. I'm not only not fond of the > proposed syntax but I also don't really see how allowing other types > in variadics will help anything. Also, there may be necessary more > complex code to support all the extr

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

I'd run this by someone who actually knows math, but afaik there are finitely many empty strings in any given string. How many e's are in any given string? (Ignoring Unicode issues for now,) for each index in the string's indices, form a substring one character in length starting at that index and

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

On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > Mathematical correct or not: > > in case of > s1.hasPrefix(s2) > (or any other containment test method) > > s1 and s2 are just plain simple instances of String, > no

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

As cannot (and should not) hide substructures and can be added later if you so desire. > On Jul 20, 2016, at 3:36 PM, L. Mihalkovic > wrote: > > Hiding is not necessary if you import into a pseudo container... It means the > ide does not have to keep track of whats here whats not on a per so

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Hiding is not necessary if you import into a pseudo container... It means the ide does not have to keep track of whats here whats not on a per source file basis Import CoreGraphics as cg cg.x Collisions are always avoided and there is only adding imports. Simple. Regards (From mobile)

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

> On 20 juil. 2016, at 14:21, Xiaodi Wu wrote: > > Doesn't your second argument undermine your first? If it's a trivial solution > and one rarely ever considers empty strings when invoking `hasPrefix`, then > returning the technically correct result must be a trivial departure in > behavior.

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

Hi, Mathematical correct or not: in case of s1.hasPrefix(s2) (or any other containment test method) s1 and s2 are just plain simple instances of String, nothing more nothing less. Which is interpreted by me as: “test if String s1 starts with String s2” which, to me, implies

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

on Wed Jul 20 2016, Dave Abrahams wrote: > on Wed Jul 20 2016, Jonathan Hull wrote: > >>> >>> Basically, I added back in a super-minimal protocol to fill the >>> >>> structural gap left by Sequence. I call it “IteratorProvider” and it >>> >>> only has a single function which vends an iterator.

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

> On 20 Jul 2016, at 11:07, Brent Royal-Gordon wrote: > >> On Jul 19, 2016, at 6:14 PM, Karl wrote: >> >> That is to say, we basically introduce “open" as an inverted “final”, and >> make all classes non-open by default. That is analogous to enabling >> whole-module-optimisation by default,

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

Regards (From mobile) > On Jul 20, 2016, at 8:44 PM, Tino Heth <2...@gmx.de> wrote: > > >>> Am 20.07.2016 um 18:20 schrieb L. Mihalkovic : >>> >>> So my advice: Be glad that you don't see such problems in your real work >>> life, and hope that the extremists who would like to completely remo

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

on Wed Jul 20 2016, Jonathan Hull wrote: >> >>> Basically, I added back in a super-minimal protocol to fill the >> >>> structural gap left by Sequence. I call it “IteratorProvider” and it >> >>> only has a single function which vends an iterator. Collection >> >>> adheres to this, and Iterator

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> * What is your evaluation of the proposal? I would be in favor if we make the change to square brackets that everyone is talking about. Otherwise I am indifferent. > * Is the problem being addressed significant enough to warrant a change to > Swift? I do feel that the current setter behavi

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

Hello to all of the community. ** What is your evaluation of the proposal?* +0.5 Agree on the motivation and 'public open class' Let's discuss 'public open func' + application to dynamic runtime ** Is the problem being addressed significant enough to warrant a change to Swift?* *

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

Regards (From mobile) On Jul 20, 2016, at 7:34 PM, John McCall via swift-evolution wrote: >>> On Jul 20, 2016, at 10:13 AM, Károly Lőrentey wrote: >>> On 2016-07-18, at 19:05, John McCall via swift-evolution >>> wrote: >>> The basic effect of Károly's counter-proposal is that every public me

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 2:35 PM, Xiaodi Wu wrote: > > > > On Wed, Jul 20, 2016 at 4:24 PM, Robert Widmann > wrote: > >> On Jul 20, 2016, at 2:19 PM, Xiaodi Wu > > wrote: >> >> On Wed, Jul 20, 2016 at 4:06 PM, Robert Widmann >

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 2:52 PM, Robert Widmann via swift-evolution > wrote: > >> >> On Jul 20, 2016, at 2:35 PM, Xiaodi Wu > > wrote: >> >> >> >> On Wed, Jul 20, 2016 at 4:24 PM, Robert Widmann > > wrote: >> >>> On Jul 20, 2016, at 2:19

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

> On Jul 20, 2016, at 2:57 PM, Jonathan Hull via swift-evolution > wrote: > >> > True, people might try to get the iterator a second time, but we can >> > make the iteratorProvider method optional (and trying to get an >> > iterator from an iterator which is spent would return nil) >> > and the

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 4:24 PM, Robert Widmann wrote: > > On Jul 20, 2016, at 2:19 PM, Xiaodi Wu wrote: > > On Wed, Jul 20, 2016 at 4:06 PM, Robert Widmann > wrote: > >> >> On Jul 20, 2016, at 2:04 PM, Robert Widmann via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Jul 20

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

> On Jul 20, 2016, at 11:44 AM, Tino Heth via swift-evolution > wrote: > > >> Am 20.07.2016 um 18:20 schrieb L. Mihalkovic > >: >> >>> So my advice: Be glad that you don't see such problems in your real work >>> life, and hope that the extremists who woul

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

On Wed, Jul 20, 2016 at 4:06 PM, Robert Widmann wrote: > > On Jul 20, 2016, at 2:04 PM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jul 20, 2016, at 1:59 PM, Xiaodi Wu wrote: > > Why is hiding in-scope but renaming out-of-scope? > > > > Because hiding and re

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 2:04 PM, Robert Widmann via swift-evolution > wrote: > >> >> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu > > wrote: >> >> Why is hiding in-scope but renaming out-of-scope? > > > Because hiding and renaming can be used in combination to subset out

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu wrote: > > Why is hiding in-scope but renaming out-of-scope? Because hiding and renaming can be used in combination to subset out APIs, not alter them. > Both are additive to Swift, As part of this proposal, both are source-breaking. > and as has be

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Why is hiding in-scope but renaming out-of-scope? Both are additive to Swift, and as has been argued by others, the former is a special case of the latter. On Wed, Jul 20, 2016 at 15:55 Brandon Knope wrote: > I meant is there any reason for requiring parentheses > > On Jul 20, 2016, at 4:53 PM,

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

> >>> Basically, I added back in a super-minimal protocol to fill the > >>> structural gap left by Sequence. I call it “IteratorProvider” and it > >>> only has a single function which vends an iterator. Collection > >>> adheres to this, and Iterator adheres to it by returning itself. All > >>>

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I meant is there any reason for requiring parentheses > On Jul 20, 2016, at 4:53 PM, Robert Widmann wrote: > > Renaming is out of scope for this proposal, that’s why. > >> On Jul 20, 2016, at 1:26 PM, Brandon Knope wrote: >> >> I prefer this 100x more >> >> Is there any reason why this woul

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

Thanks for the feedback, everyone. I revised the proposal a bit in light of design, implementation, and scheduling discussions we've had in the process of implementation: https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md • Subset out conditional ambivalent

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Renaming is out of scope for this proposal, that’s why. > On Jul 20, 2016, at 1:26 PM, Brandon Knope wrote: > > I prefer this 100x more > > Is there any reason why this wouldn't work? > > Brandon > > On Jul 20, 2016, at 4:13 PM, Xiaodi Wu > wrote: > >> Yeah, I'd

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

> On Jul 8, 2016, at 11:19 AM, Ben Langmuir wrote: > > Hey Joe, Sorry Ben, missed this when you sent it a couple weeks ago. > I’m +1 on the overall direction, but I have some questions/concerns about the > "Ambivalent dynamic casting from Any” section. > > 1) When you suggest that `x as Stri

Re: [swift-evolution] [Proposal] Variadics as Attribute

I'm also having trouble getting behind this proposal. IMO, variadics as implemented today in Swift (and in Java) are a subset of the problems that can be solved with variadic generics. They're more limited because you can't today support heterogeneous argument lists without losing static type info

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I prefer this 100x more Is there any reason why this wouldn't work? Brandon > On Jul 20, 2016, at 4:13 PM, Xiaodi Wu wrote: > > Yeah, I'd be happy to lose the parentheses as well. > > In the last thread, my take on simplifying the proposed syntax was: > > ``` > import Swift using String, In

Re: [swift-evolution] [Proposal] Variadics as Attribute

I'm strongly opposed to this too. I'm not only not fond of the proposed syntax but I also don't really see how allowing other types in variadics will help anything. Also, there may be necessary more complex code to support all the extra (or even previously unknown) types that could be used with thi

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

What you said back then lead me to understand you did not get the difference. Forgive me if it wasn't the case but I've also seen it happen more than once in this list, hence the repeatition. I also understand that there are other ways to implement the same behaviour we want without sealed by defau

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

On Wed, Jul 20, 2016 at 1:14 PM Guillaume Lessard via swift-evolution < swift-evolution@swift.org> wrote: > > > On 20 juil. 2016, at 12:42, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote: > > > > +1 > > this should be a bugfix. > > First, NSString’s prefix function retu

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

Doesn't your second argument undermine your first? If it's a trivial solution and one rarely ever considers empty strings when invoking `hasPrefix`, then returning the technically correct result must be a trivial departure in behavior. On Wed, Jul 20, 2016 at 15:14 Guillaume Lessard via swift-evo

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

> On 20 juil. 2016, at 12:42, Michael Peternell via swift-evolution > wrote: > > +1 > this should be a bugfix. First, NSString’s prefix function returns false for empty string parameters, and this would be a significant departure in behaviour. Second, while an empty string is technically a p

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Yeah, I'd be happy to lose the parentheses as well. In the last thread, my take on simplifying the proposed syntax was: ``` import Swift using String, Int // or, for hiding: import Swift using Int as _ ``` The key simplification here is that hiding doesn't need its own contextual keyboard, espe

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

On Mon, Jul 18, 2016 at 3:29 PM, Dave Abrahams via swift-evolution wrote: > > on Mon Jul 18 2016, Kevin Nattinger wrote: > >> I agree, true is definitely the expected behavior. In particular, it >> seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be >> false when `a == b` is tr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

> On Jul 20, 2016, at 1:00 PM, Arnold wrote: > > > > Sent from my iPhone > >> On Jul 20, 2016, at 12:47 PM, Dave Abrahams wrote: >> >> >> on Wed Jul 20 2016, Arnold Schwaighofer wrote: >> On Jul 20, 2016, at 9:54 AM, Andrew Trick wrote: > On Jul 20, 2016, at 9:44 AM

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

on Wed Jul 20 2016, Michael Peternell wrote: > +1 > this should be a bugfix. PRs for bugfixes always appreciated. >> Am 18.07.2016 um 19:36 schrieb Chris Denter via swift-evolution >> : >> >> Hello – >> >> Currently, the standard library String functions .hasPrefix() and >> .hasSuffix() wil

  1   2   >