Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 7, 2016, at 7:14 AM, Douglas Gregor wrote: > > >> On Jun 6, 2016, at 10:08 PM, Thorsten Seitz wrote: >> >> >> >>> Am 06.06.2016 um 22:13 schrieb L Mihalkovic : >>> >>> > On Jun 6, 2016, at 9:34 PM,

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 10:08 PM, Thorsten Seitz wrote: > > > > Am 06.06.2016 um 22:13 schrieb L Mihalkovic >: > >> >>> On Jun 6, 2016, at 9:34 PM, Douglas Gregor >>

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> Am 06.06.2016 um 22:13 schrieb L Mihalkovic : > > >>> On Jun 6, 2016, at 9:34 PM, Douglas Gregor wrote: >>> >>> >>> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz wrote: >>> >>> >>> >>> Am 06.06.2016 um 18:51 schrieb

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

Michael Ilseman wrote: > The biggest issue with the proposal as written is with importing a typedef > as an enum. Enums do not allow us to control the underlying storage, > and thus we would constantly be paying a bridging cost in its use. > [...] > The second issue concerns importing bridged

[swift-evolution] Studying the evolution of the Swift project

Hi there, I'm a researcher studying software evolution. As part of my current research, I'm studying the implications of open-sourcing a proprietary software, for instance, if the project succeed in attracting newcomers. Swift was in my list. To further analyze the impacts of Swift’s migration,

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

Michael Ilseman wrote: > The biggest issue with the proposal as written is with importing a typedef > as an enum. Enums do not allow us to control the underlying storage, > and thus we would constantly be paying a bridging cost in its use. > [...] > The second issue concerns importing bridged

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> Le 3 juin 2016 à 17:11, Erica Sadun via swift-evolution > a écrit : > > Discussion has more or less drawn down. Are there any further significant > requests / issues that need addressing? Both standalone functions (my > recommended approach) and the MemoryLayout

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] Marking sort and sorted with rethrows

on Sun Jun 05 2016, Haravikk wrote: >> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution >> wrote: >> >> Most standard library functions that take a closure allow that >> closure to throw (and those functions are subsequently

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

> E.g. with the proposal, the following function: > > @noreturn func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > has to be written as > > func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > It still returns bottom, but there is no way to

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

On Sat, Jun 4, 2016, at 11:24 AM, Chris Lattner via swift-evolution wrote: > * What is your evaluation of the proposal? +1 in general, but I still think String.init(describing:) is annoyingly long and would prefer String.init(from:). Also, I'm a little concerned by this bit: > As a

Re: [swift-evolution] Add a while clause to for loops

Personally, given this discussion and the one about `where` in if and while statements, I would not be opposed to elimination of `where` in control statements altogether. My reasoning would be that words like filter and prefix unambiguously indicate what happens to elements of a sequence for

Re: [swift-evolution] [Proposal] A more liberal placement of defer

This proposal runs counter to the spirit of what defer seems to be meant for in the first place. It’s to save you forgetting to do something (like closing a stream) before you exit a block of code. If you push it down in the code to after the return, then you might as well have just put the

Re: [swift-evolution] Add a while clause to for loops

I didn’t mean we should really get rid of the `where` clause, it’s great. I guess the point I was trying to make is that we can use a `where` clause with a `for` loop in Swift, despite the existence of the `filter` method. So despite `prefix(while:)` in Swift 3, there might be room for a

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

SE-0033 and SE-0044 are already "Implemented in Swift 3" according to both the proposals and the README, but not according to the bug tracker: (I can't find a bug report for SE-0033). The

Re: [swift-evolution] [swift-users] WWDC Meetup

+1 I'd love to put some faces to some names :) sounds fun! Shane On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users > wrote: I'd be interested in catching up. Was curious if there was going to be a meet up, either formal or informal.

Re: [swift-evolution] [Proposal] A more liberal placement of defer

While I can kind of see where you’re coming from I’m not sure about the change; the key thing about defer is that it doesn’t just execute in the cases you explicitly define, but can also occur if exceptions are thrown and other exit cases that could be all over the scope. To compare with other

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Mon Jun 06 2016, Nate Cook wrote: > I'd like to cast another vote in favor of something like the > MemoryLayout struct. In general, people aren't always making the right > choice about which of these values to use. Combining them into one > data type would mean they see that there are three

Re: [swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

> On Jun 6, 2016, at 1:59 PM, Ross O'Brien via swift-evolution > wrote: > > Given a protocol with an associated type: > > protocol Foo > { > associatedtype Bar > } > > it should be possible to define a protocol conforming to Foo, for which Bar > can be

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Not sure I see how they're in different scopes. Can you explain that to me? -- E > On Jun 6, 2016, at 2:18 PM, donny wals wrote: > > Erica, > > Maybe my phrasing was a bit off, but in my proposal it’s really important > that the return and the defer are in the same

Re: [swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

Wouldn't this be covered under SE-0092? On Mon, Jun 6, 2016 at 15:59 Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote: > Given a protocol with an associated type: > > protocol Foo > { > associatedtype Bar > } > > it should be possible to define a protocol conforming to Foo,

Re: [swift-evolution] Add a while clause to for loops

The burden of proof for adding new features is different from that for taking away existing features. If a feature doesn't yet exist, a successful proposal will show how it provides additional and non-trivial utility. If a feature already exists, a successful proposal to remove it will show how

Re: [swift-evolution] SE-0045 status?

on Mon Jun 06 2016, Erica Sadun wrote: > Did we ever get to a stopping point on SE-0045, with the take while / > drop while methods? I remember we were discussing using prefix / > suffix and a bunch of other names, but was the consensus ever fully > settled? I'm going back through the gmane

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 6, 2016, at 3:48 PM, michael.petern...@gmx.at wrote: > > Yes, ok... > > Well, I cannot easily make everything synchronous. I just can change it in a > way that makes a `@required` attribute "optional" ;) > > import Foundation > > enum Result { >case success(T) >case

[swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

Given a protocol with an associated type: protocol Foo { associatedtype Bar } it should be possible to define a protocol conforming to Foo, for which Bar can be typealiased: protocol IntFoo : Foo { typealias Bar = Int } such that all conformers to IntFoo now have an associatedtype Bar

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

> > @noreturn func error(msg: String = "") -> T { > fatalError("bottom: \(msg)") > } > has to be written as > func error(msg: String = "") -> T { > fatalError("bottom: \(msg)") > } > It still returns bottom, but there is no way to say so in the declaration. > The proposal just made the

Re: [swift-evolution] Add a while clause to for loops

I brought up this suggestion in December: http://thread.gmane.org/gmane.comp.lang.swift.evolution/1759 Jacob On Mon, Jun 6, 2016 at 3:15 AM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > We can already use a where clause in a for loop like this: > > for element in

Re: [swift-evolution] Pitch: @required attribute for closures

> Am 06.06.2016 um 22:30 schrieb Charles Srstka via swift-evolution > : > > On Jun 6, 2016, at 2:49 PM, Michael Peternell > wrote: >> >> That's really hard to answer in the general case. I think real proposals >> should contain concrete,

Re: [swift-evolution] [Proposal] A more liberal placement of defer

>And simple functions like fibonacci I would just write without using `defer` >at all - it's just confusing to use `defer` and `inout` in this case IMO. > > /// Calculates the n'th fibonacci number. (n>= 1) > func fibonacci(n: Int) ->Int { > var a = 0 > var b = 1 > for _ in 1...n { > (a,b)=(b,

Re: [swift-evolution] Add a while clause to for loops

The functionality of the `where` clause in `for` loops also already can be mimicked using `filter`. Wouldn’t we have to get ride of the `where` clause by that logic? > The functionality being asked for here is already accepted for inclusion to > Swift as a method on Sequence named

[swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

During implementation, I’ve come up with some problems with SE-0033  as written, and am proposing some changes to the proposal. I’d like to present them here for early discussion, and will write up a

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Hi, That’s fair enough. IMO structuring code so it reads in the same order it executes is an opportunity to simplify code rather than complicate it. However, I do agree that the fibonacci example I mentioned earlier might not be the best use case and it’s probably the best use case for this

Re: [swift-evolution] Pitch: @required attribute for closures

On Jun 6, 2016, at 2:49 PM, Michael Peternell wrote: > > That's really hard to answer in the general case. I think real proposals > should contain concrete, realistic examples that show the benefit of the > proposal. It's really hard to argue against a proposal if

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Hi, I think that's an awful idea. I can already tell you that this will never be accepted. It just complicates the design and the semantics of the `defer` statement, and I don't see any advantage. Sorry. -Michael > Am 06.06.2016 um 22:14 schrieb donny wals via swift-evolution >

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Erica, Maybe my phrasing was a bit off, but in my proposal it’s really important that the return and the defer are in the same scope. In your example the allocate memory line is in a different scope that the guard/else statements. Therefor, the defer { release memory } shouldn’t be executed if

Re: [swift-evolution] Add a while clause to for loops

The functionality being asked for here is already accepted for inclusion to Swift as a method on Sequence named `prefix(while:)` (SE-0045): `for element in array.prefix(while: { someCondition($0) }) { ... }` On Mon, Jun 6, 2016 at 14:31 T.J. Usiyan via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Michael, How would this proposal break your snippet? > func g(x: Int) { >defer { print("A"); } >let b: Int >if x == 3 { >return >} else { >b = x >} >defer { print("b is \(b)") } > } In this case if x==3 the function should return without executing the

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 9:34 PM, Douglas Gregor wrote: > > >> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz > > wrote: >> >> >> >> Am 06.06.2016 um 18:51 schrieb Douglas Gregor >

Re: [swift-evolution] [Proposal] A more liberal placement of defer

This is problematic. You may want to defer code at different points with different reasons. For example, you might not want to trigger defer until after some preconditions have been met.: guard something guard something allocate memory; defer {release memory} -- E > On Jun 6, 2016, at 1:50

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Hi, you may think of `defer` as a function that pushes a block onto an implicit cleanup stack that is part of every lexical closure. On each scope exit, all blocks from its cleanup stack are popped and executed. E.g.: func f(x: Int) { defer { print("A"); } defer { print("B"); } if

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

> On 06 Jun 2016, at 22:40, Michael Peternell via swift-evolution > wrote: > > E.g. with the proposal, the following function: > > @noreturn func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > has to be written as > > func error(msg:

[swift-evolution] [Proposal] A more liberal placement of defer

Hi, When we’re using defer we write some code that we want to execute the moment a scope exits. This leads to code that could read like: let fibonacci = sequence(state: (0, 1)) { (pair: inout (Int, Int)) -> Int in defer { pair = (pair.1, pair.0 + pair.1) } return pair.0 } What I find

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 12:37 PM, L Mihalkovic > wrote: > >> >> On Jun 6, 2016, at 6:51 PM, Douglas Gregor > > wrote: >> >>> >>> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >>>

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

> Am 06.06.2016 um 00:53 schrieb Charles Srstka : > >> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution >> wrote: >> >>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution >>> : >>>

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 6:51 PM, Douglas Gregor wrote: > >> >> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >> > wrote: >> >> The issue is to decide on the applicability scope. Thinking 'my

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz wrote: > > > > Am 06.06.2016 um 18:51 schrieb Douglas Gregor >: > >> >>> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >>>

Re: [swift-evolution] [Proposal] Add property for negation to Bool

I appreciate your support but looks like this proposal is going nowhere. This proposal affects fundamental habits that are very hard to argue with. Never the less I will keep using this property in my code because my team is okay with it. Thanks, Anton Mironov > 6 черв. 2016 р. о 21:42

Re: [swift-evolution] Add a while clause to for loops

> Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via swift-evolution > : > > I also considered `until`, but it would be a bit confusing that `where` makes > sure a condition is met, while `until` makes sure the condition isn’t met. I > think `while` makes more sense

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

> On Jun 6, 2016, at 12:02 PM, Rob Norback via swift-evolution > wrote: > > First of all, thank you all for bringing me up to date so quickly. I looked > over the proposal and it looks awesome. > > But as Chris mentioned, this doesn't solve the expected behavior

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> Am 06.06.2016 um 18:51 schrieb Douglas Gregor : > > >> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >> wrote: >> >> The issue is to decide on the applicability scope. Thinking 'my app/their >> stuff' is an illusion. To the

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

Yes, Rob, even though our proposals are very related, I do think that yours would fit better in a new proposal. My first draft was also in regards to change the default behaviour - not focused on optionals though. It went through a discussion about *masking* the current fail fast behaviour (e.g.

Re: [swift-evolution] Feature proposal: Range operator with step

Thorsten Seitz via swift-evolution writes: > > > Am 03.05.2016 um 13:42 schrieb Hans Huck via swift-evolution swift.org>: > > > > Thorsten Seitz via swift-evolution ...> writes: > >> > >> -1 > >> > >> I don't see the need for special syntax where a method can be easily

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

I created a draft proposal to make `@noescape` the default and created a new email thread with subject "[Proposal] Make non-escaping closures the default". On Thu, Jun 2, 2016 at 1:22 AM, Chris Lattner wrote: > > On Jun 1, 2016, at 9:22 PM, Trent Nadeau

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

Am 18.05.2016 um 20:52 schrieb Brent Royal-Gordon via swift-evolution : >>> If we're doing this, I wonder if category 1 shouldn't just be >>> `Convertible`. This would preserve our `LiteralConvertible` protocols with >>> the same names (which, consistency issues

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

Apologies, please remove the line "Right now myArray[100] = nil gives you EXC_BAD_INSTRUCTION." from my previous email so it makes more sense to read. On Mon, Jun 6, 2016 at 12:02 PM Rob Norback wrote: > First of all, thank you all for bringing me up to date so quickly. I >

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

First of all, thank you all for bringing me up to date so quickly. I looked over the proposal and it looks awesome. But as Chris mentioned, this doesn't solve the expected behavior and ambiguity of ```Array``` In this case I would expect the default behavior (myArray[4]) without using

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

Ceylon demonstrates other uses for the bottom type than just marking @noreturn methods, e.g. (mixing Ceylon and Swift syntax freely here) class Iterable { var last: Element | Absent // remember that optionals in Ceylon are modeled as union type T | Null

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

Thanks Vladimir, The correct link is this one (with the additional min/max operations in the implementation): https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/-more-lenient-collections-subscripts.md Here is the pull request on the swift-evolution

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

What about `PreconditionFailure`? If you obtain an instance of this type, it means a precondition has failed. Jacob On Mon, Jun 6, 2016 at 9:48 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > `Never` seems reasonable to me too. I'll add that to the proposal as an >

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

The proposal needs to discuss arrays of optionals e.g.: ```Array``` These are not just legal, they are quite handy as well. Dictionaries can also be declared with optional values, of course: ```Dictionary``` These can be pretty confusing to deal with and we should not add to

Re: [swift-evolution] Add a while clause to for loops

I also considered `until`, but it would be a bit confusing that `where` makes sure a condition is met, while `until` makes sure the condition isn’t met. I think `while` makes more sense because it corresponds to `break` in the same way that `where` corresponds to `continue`. >`while`, to me,

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

I'd love to join in > On Jun 6, 2016, at 10:04 AM, T.J. Usiyan via swift-corelibs-dev > wrote: > > I will be in San Francisco during WWDC as well. > >> On Mon, Jun 6, 2016 at 12:03 PM, Michael Sheaver via swift-evolution >> wrote: >>

Re: [swift-evolution] [swift-users] WWDC Meetup

I'll be in San Fran during WWDC and would love to Meetup! > On Jun 6, 2016, at 11:03 AM, Michael Sheaver via swift-evolution > wrote: > > I am attending WWDC and would love to attend this proposed meetup - if you > all can tolerate a Swift baby who is just learning

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

Please find this draft of proposal(hope this is correct link for latest version): https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md The main idea is to introduce 2 new subscript methods: [clamping:] and [checking:]

Re: [swift-evolution] [swift-users] WWDC Meetup

I will be in San Francisco during WWDC as well. On Mon, Jun 6, 2016 at 12:03 PM, Michael Sheaver via swift-evolution < swift-evolution@swift.org> wrote: > I am attending WWDC and would love to attend this proposed meetup - if you > all can tolerate a Swift baby who is just learning to crawl! :)

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution > wrote: > > The issue is to decide on the applicability scope. Thinking 'my app/their > stuff' is an illusion. To the compiler & runtime there is only code split > into modules, some in source code

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

`Never` seems reasonable to me too. I'll add that to the proposal as an alternative. -Joe > On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution > wrote: > > I vote for Bottom or Never. None does not convey "this should not occur or be > evaluated". > >

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

IMHO there is a deep relationship between this discussion, 0092 and a serie of other recent topics (like literal convertibles or the extended existentials). There is no doubt that these questions must and will all be answered individually, however it is my HO that there is a small window of

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

> On Jun 5, 2016, at 11:27 PM, L. Mihalkovic > wrote: > > > > > Regards > (From mobile) > On Jun 6, 2016, at 1:20 AM, Douglas Gregor via swift-evolution > > wrote: > >> >>> On May 18, 2016, at

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

On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > I'd argue that it's more important for the language to be clearly readable > than to satisfy a notion of absolute adherence to pure formal semantics > that only theorists would completely

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

I'd like to cast another vote in favor of something like the MemoryLayout struct. In general, people aren't always making the right choice about which of these values to use. Combining them into one data type would mean they see that there are three related values and can find out when to use

Re: [swift-evolution] [swift-users] WWDC Meetup

Great initiative—and a really interesting question: how many Swift Open Source people attend WWDC? > On 06.06.2016, at 08:35, David Hart via swift-users > wrote: > > I imagine that during WWDC a non-negligible proportion of the Swift Open > Source contributors will be

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

> I'd argue that it's more important for the language to be clearly readable > than to satisfy a notion of absolute adherence to pure formal semantics that > only theorists would completely understand. The semantics might help a person better understand the philosophy of the language. The

[swift-evolution] SE-0045 status?

Did we ever get to a stopping point on SE-0045, with the take while / drop while methods? I remember we were discussing using prefix / suffix and a bunch of other names, but was the consensus ever fully settled? I'm going back through the gmane archive, the SE repo, and the 5-31 dev build and

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

Trent Nadeau wrote: > ### Imported C/Objective-C APIs > > Per the Core Team, most Cocoa closure/block parameters are escaping > (e.g., delegates). As such the Clang importer will automatically add > the `@escaping` annotation to closure/block parameters encountered in > imported Objective-C APIs

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

"Nothing" feels like it collides too much with the concept of a function that returns, but returns nothing (i.e., Void), however. If I read a function declaration from left to right: func foo() -> Nothing I read that as "a function foo that returns nothing". That sounds like a Void function

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

You are thinking of it as a return type, but that's not how you should think of it, really - that's an example of what it may be used for, but it should not be the only aspect. It should be the opposite of Any, which (excluding None), seems to be Nothing. Or Singularity :) 6. 6. 2016 v 16:12,

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

The question regarding FloatingPoint. Now we have: var float = 1.0/3.0 var s = "\(float)" print(s) // 0.333 What we'll have after the proposal implemented? As stated in proposal: Standard library types to conform -> The following standard library types and protocols should be

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

In this case not just "Serializable" but "StringSerializable", no? On 05.06.2016 6:25, David Sweeris via swift-evolution wrote: On Jun 4, 2016, at 15:46, Jacob Bandes-Storch via swift-evolution wrote: - The "lossless" protocol will be a welcome addition for

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

+1 for Never, as 'foo() -> Never' reads as 'foo returns never' i.e. close to 'never returns'. Or we just need NoReturn as replacement for @noreturn, and then think about true bottom type and its name separately. On 06.06.2016 16:37, Thorsten Seitz via swift-evolution wrote: My preference from

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

Actually I don’t like the prioritization of the modules import. I’m much more in favor of disambiguating at call site. like we have to do in any other case of ambiguity in Swift. The concept of precedence is only present in operators and that makes sense because it’s in their nature. I think #4

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

My preference from the current suggestions would be Never. -Thorsten > Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution > : > > Ceylon uses `Nothing` for the bottom type. > > -Thorsten > >> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via

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

Ceylon uses `Nothing` for the bottom type. -Thorsten > Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution > : > > While None is probably the best way to describe the opposite of Any, it would > be often mistaken for .None (i.e. Optional) by newcomers

Re: [swift-evolution] WWDC Meetup

I'd be interested in catching up. Was curious if there was going to be a meet up, either formal or informal. Sounds good. -Rod > On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution > wrote: > > I imagine that during WWDC a non-negligible proportion of the

[swift-evolution] Add a while clause to for loops

We can already use a where clause in a for loop like this: for element in array where someCondition(element) { // … } which basically acts like for element in array { guard someCondition(element) else { continue } // … } Sometimes you want to break out of the loop when the

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

>> This is a language that has put protocol centerstage. It stands to reason >> express something as essential using a protocol. >> >> protocol Nothing {} >> >> seems more than rational > > No, this doesn't make sense as a protocol. You should not be able to conform > to Nothing, but you

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

> Why? The compiler flags an error if it can statically prove a trapping overflow will occur. Why shouldn't it flag an error if it can statically prove a force unwrap will fail? > If one of the associated values is Bottom/None/Never, how is my code improved by the fact that I still need a case for

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

> Bringing up an old idea, we could rewrite `rethrows` using Never and throws > type specification: > > func call(block: () throws E -> T) throws E -> T > > But this requires some compiler magic: non-throwing functions should > effectively become functions throwing Never. This is very

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

> This is a language that has put protocol centerstage. It stands to reason > express something as essential using a protocol. > > protocol Nothing {} > > seems more than rational No, this doesn't make sense as a protocol. You should not be able to conform to Nothing, but you could conform

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

> I'd personally prefer calling it "Nil" (capital N), which really means > "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class. > Possibly, to avoid confusion with nil, calling it Null? Though that might get > confused with NSNull, once the NS prefix gets dropped. I don't

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

> The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I discussed all of these options and more. The issue I see with None is that it could easily be interpreted as Void to those

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

Loved the insight about the positive net effect on language symmetry, quite important yet sometimes the unsung hero of such discussions :). Sent from my iPhone > On 6 Jun 2016, at 08:26, David Hart via swift-evolution > wrote: > > >>• What is your evaluation

[swift-evolution] WWDC Meetup

I imagine that during WWDC a non-negligible proportion of the Swift Open Source contributors will be in or around San-Francisco. I’d very much like to profit from that opportunity to meet-up, get to know each other, talk Swift over some beers! Is anybody interested? If yes, any ideas for

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> • What is your evaluation of the proposal? +1 I’ve always been annoyed by the complicated grammar of condition clauses. This proposal simplifies them and makes them easier to understand and teach. Especially, I regret that the syntax for A && B is different than B && A when A is a

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

> On Jun 6, 2016, at 8:25 AM, David Hart via swift-evolution > wrote: > > I'm against using Nil as it would have a very different meaning than Nil (or > Null) in all other C-based languages. Well said :) >> On 06 Jun 2016, at 05:56, Charlie Monroe via

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

• What is your evaluation of the proposal? -1 for the current proposal, +1 for being able to mix regular boolean expressions and `let` expressions. • Is the problem being addressed significant enough to warrant a change to Swift? Yes, not being able to mix different clause types feels

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

I'm against using Nil as it would have a very different meaning than Nil (or Null) in all other C-based languages. > On 06 Jun 2016, at 05:56, Charlie Monroe via swift-evolution > wrote: > > Adding a Nil *type* is a bit different than casting dozen of identifiers to