Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

>.. To me, it feel like extra syntax where the -> is already making it very clear that we're dealing with a function... Can't agree with you. I don't think it's "very clear" where the function and where is result type here: Int -> String -> Void -> Float in compare to this: (Int) -> (Strin

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

(Sorry to be hijacking a different subthread, but I only just subscribed again to the mailing list) I understand why the proposal has its benefits. Yet, if we look at the SE-0009 rationale, we could apply much of that as an argument against this proposal, e.g. "anything that is widely repeated bec

Re: [swift-evolution] [Proposal] Safer half-open range operator

We already have this feature(to append labels for substiption), so I believe it is possible to implement this proposal: class A { subscript(safe range: Range) -> [Int] { get { return [1,2,3] } set { print(newValue) } } subscript(truncate range: Range) -> [Int] { get

Re: [swift-evolution] multi-line string literals.

+1 for Brent's comments On Sunday, 24 April 2016, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > Instead of creating yet another set of string quotation rules, I would > prefer copy & pasting the Perl 5 rules :) > > I wouldn't. > > I'm a big fan of Perl. It was my

[swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

Currently, Comparable looks like this: public protocol Comparable : Equatable { /// A [strict total order](http://en.wikipedia.org/wiki/Total_order#Strict_total_order) /// over instances of `Self`. @warn_unused_result func < (lhs: Self, rhs: Self) -

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

A few things… First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that. > public

[swift-evolution] [Idea] Repurpose Void

SE-0066 disallows Void to be used on left side of function types. Some people, including me, argue that Void should be removed altogether, because: 1) () is more consistent with curried functions: (Int) -> () -> Double 2) () follows functional programming traditions Now, why don't we repurpose Vo

Re: [swift-evolution] multi-line string literals.

> Instead of creating yet another set of string quotation rules, I would prefer > copy & pasting the Perl 5 rules :) I wouldn't. I'm a big fan of Perl. It was my daily driver for many years. I participated in the Perl 6 design process, was pumpking for a Parrot (the early Perl 6 interpreter) s

Re: [swift-evolution] Guaranteed closure execution

> Le 23 avr. 2016 à 18:33, Timothy Wood a écrit : > > > >> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution >> > [...] >> >> Since @once actually implies @noescape (as described earlier in the thread), >> it can be shortened to: > [...] > > I'm surprised that @once would impl

Re: [swift-evolution] multi-line string literals.

Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :) let x = XMLDocument(< it works END_OF_XML /* I think multiline literals should not consider indentation. If you want to have it formatted nicely, the editor should display a nice

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

If you wrote: enum Ex { case one, two, three } And the compiler translated that into the equivalent of: - struct Ex : OptionSetType { - let rawValue: UInt - init(rawValue: UInt

Re: [swift-evolution] Overriding computed properties with let constants?

Oh, yeah, good point about "final". Would there be a performance difference between "override var x: Int {return 7}" and "override let x = 7"? Sent from my iPhone > On Apr 23, 2016, at 16:06, Haravikk via swift-evolution > wrote: > > I don’t think using a let constant should prevent a furthe

Re: [swift-evolution] multi-line string literals.

> I’ve raised a speculative PR against the Swift Lexer to support multi-line > string literals Wow, it's pretty cool that this change is so surgical. > I’m trying to avoid more advanced features such as the handling of indenting > which > for me complicates something that if kept simple can be

Re: [swift-evolution] Overriding computed properties with let constants?

I don’t think using a let constant should prevent a further sub-class from overriding again, that’s what the final keyword should be for. It would still need to be implemented like this behind the scenes though: override var x:Int { return 7 } By the same token you could also allow var to i

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall > wrote: >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > > wrote: >> On Fri, Apr 22, 2016 at 10:50 PM, John McCall >

Re: [swift-evolution] Overriding computed properties with let constants?

I’m not sure if I like it, but declaring it as a let could disallow subclasses from overriding it, just like any other let. - Dave Sweeris > On Apr 23, 2016, at 2:30 PM, Adrian Zubarev via swift-evolution > wrote: > > I already see the problem here: > > class A { var x: Int { return 42 } } >

Re: [swift-evolution] Notes from Swift core team 2016-04-20 design discussion

Ah, yes, you are right, I didn’t think of configuring delegates when the delegate ist set. -Thorsten > Am 22.04.2016 um 19:04 schrieb David Waite : > > Sure, but I personally want to configure delegates early, when the delegate > is set. > > It may be inappropriate to send a synthetic messag

Re: [swift-evolution] Overriding computed properties with let constants?

I already see the problem here: class A { var x: Int { return 42 } } class B: A { override let x = 7 } // assume that will work class C: B { override var x: Int { /* wait this wont work anymore */ } } You won’t be able to override an immutable constant. I don’t like such a change. --  Adrian Zu

[swift-evolution] Overriding computed properties with let constants?

I think, it could be a good idea to make computed properties overridable with let constants. Something like this: class Parent { var x: Int { let x = 42 /* * Compute x... */ return x } } class Child: Parent { /* * Sometimes you need to

Re: [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()

+1. I believe the proposal should be accepted. However, cross-platform libraries would still need to write: #if os(OSX) || os(iOS) || os(tvOS) || os(watchOS) import func ObjectiveC.autorelease

Re: [swift-evolution] Properties with parameters

Tim Vermeulen via swift-evolution writes: > Properties are great. They allow us to write the more naturally looking > > myButton.hidden = true > > instead of > > myButton.setHidden(true) > > However, they don't take any parameters. That’s why we still have to write > > myButton.setImage(myIm

Re: [swift-evolution] multi-line string literals.

This is oversimplifying the problem of escaping. Simply relaxing the grammar for the content of the string literal doesn't always work. For example, a regular expression that detects a might be written "\N*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does no

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Sat, Apr 23, 2016 at 4:51 AM, Michael Peternell wrote: > In my opinion, requiring something is almost never something that I would > describe as a "feature". I agree with this completely. > I don't really care if the keyword is called "optional" or "objcoptional", > I think both are fine,

Re: [swift-evolution] Guaranteed closure execution

Oh, and I forgot to mention that this would mean deinit would need to extract the block it it hadn't been done already. I would hope (to avoid silent errors) that the compiler would require a reference type with an @once property to have a deinit that checks for a lingering value and deals with

Re: [swift-evolution] Guaranteed closure execution

> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution > [...] > > Since @once actually implies @noescape (as described earlier in the thread), > it can be shortened to: [...] I'm surprised that @once would imply @noescape. In my opinion this makes it much less useful. For example,

Re: [swift-evolution] Guaranteed closure execution

> Le 23 avr. 2016 à 15:47, michael.petern...@gmx.at a écrit : > > why not just write > >func f(closure: @once () -> ()) // ? > > Because, to be honest, I don't want to have to learn the difference between > an "argument qualifier" and a "type attribute". I'm with you here, but I will cer

Re: [swift-evolution] Guaranteed closure execution

Hi, > Am 23.04.2016 um 14:56 schrieb Gwendal Roué via swift-evolution > : > > Thanks for your input Michael, > > You're right that argument modifiers should go before the argument, and type > qualifiers before the type: > > func f(@once closure: @noescape () -> ()) > > Since @once actu

[swift-evolution] Properties with parameters

Properties are great. They allow us to write the more naturally looking myButton.hidden = true instead of myButton.setHidden(true) However, they don't take any parameters. That’s why we still have to write myButton.setImage(myImage, forState: .Normal) instead of myButton.imageForState(.Norma

Re: [swift-evolution] Guaranteed closure execution

I agree, it would be good if someone like Brent or Chris could chip in. However, I think that @noescape(once) is still fine. As long as a @noescape(once) closure must either be passed to a single function, or called once it seems enforceable. I don't believe a @noescape closure can be stored, so

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

While I know it might be a bit strange to have different rules for each side, I think I prefer empty brackets on the left and Void on the right, but in combination with required parenthesis on the left. So we’d have: () -> Void // yes Void -> () // no

Re: [swift-evolution] Guaranteed closure execution

Thanks for your input Michael, You're right that argument modifiers should go before the argument, and type qualifiers before the type: func f(@once closure: @noescape () -> ()) Since @once actually implies @noescape (as described earlier in the thread), it can be shortened to:

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

> On 7 Apr 2016, at 18:54, Dmitri Gribenko via swift-evolution > wrote: > > On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via swift-evolution > wrote: >> But. .successor() .predecessor() methods for Int values do not follow these >> rules for overflow situations. I.e. : >> let i : Int8 = Int8.ma

Re: [swift-evolution] Guaranteed closure execution

Hi Gwendal, > Am 23.04.2016 um 12:18 schrieb Gwendal Roué via swift-evolution > : > > Hello Andrew, > > I'm rather embarrassed: the initial design of this proposal was based on a > modifier of @noescape: > > func f(@noescape(once) closure: () -> ()) { … } > > But since the 0049 proposa

Re: [swift-evolution] [Discussion] "with" statement/method

> Note that function like this : > func with(item:T, apply:(T)->Void) { apply(item) } > > Produces such kind of problems: > struct A {var x = 1} > let a1 = A() // constant > with (a1) { $0.x = 10 } // this will be compiled without errors/warnings This works as expected (giving a compile error f

[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> > Therefore the impermissible: > (()) -> () Is identical to: > (Void) -> () So to follow these rules, it must instead be: > Void -> () … and we’re back to T1 -> T2 :* )* Wrong! If we enforce parentheses in function types, we won't be able to write Void -> () Parentheses will be required on th

[swift-evolution] SR-1246: Inconsistent naming and declaration of String & NSString derivative properties and functions

Hello, I have been advised to post the bug report https://bugs.swift.org/browse/SR-1246 on swift-evolution, so here it is: In the latest swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a.xctoolchain (master), there are inconsistencies in the following declarations: extension String { public

Re: [swift-evolution] Guaranteed closure execution

Hello Andrew, I'm rather embarrassed: the initial design of this proposal was based on a modifier of @noescape: func f(@noescape(once) closure: () -> ()) { … } But since the 0049 proposal has been accepted (https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-au

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

In my opinion, requiring something is almost never something that I would describe as a "feature". I don't really care if the keyword is called "optional" or "objcoptional", I think both are fine, but I wouldn't want it to read "@objc optional". The "@objc" in "@objc optional" should be optional

Re: [swift-evolution] [Proposal] Safer half-open range operator

No, I got the half-joke on the python-like example. :-) I meant the label as part of the brackets content, right before the range itself. E.g. [truncate: Range] where "truncate" is the label I'm referring to. Thanks - Luis On Friday, April 22, 2016, Dave Abrahams via swift-evolution < swift-evo

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

I'd like to second James Campbell's suggestion of a `mutate` keyword. Clarifying comments inline below: > On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution > wrote: > > This is not a new idea. Something almost identical to this has been > explored and discussed quite thoroughly alre

[swift-evolution] [Idea] implicit protocols and type oriented protocols

Hello Swift community, I’d like to throw a few more ideas on what features future Swift version might or should have. I’d like to talk about implicit protocols for reference and value types first and then about type oriented protocols. As everyone know Swift has a great differentiation between r