Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

When you access a static member of a type using the dot shortcut, Swift evaluates the expression immediately. Are you proposing that when you access a member of an instance, Swift generate a closure? Or are you proposing that Swift generate a closure or not depending on how the expression's value

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 05:45 PM, Joe Groff wrote: > >> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: On Fri, Dec 18, 2015, at 04:

Re: [swift-evolution] [Review] Require self for accessing instance members

* What is your evaluation of the proposal? +1. I support this proposal, although I would be in favor of making it optional via a command-line switch on the compiler, as a courtesy to those who don’t agree. * Is the problem being addressed significant enough to warrant a change to Swift? Yes.

Re: [swift-evolution] [Review] Constraining AnySequence.init

On Fri, Dec 18, 2015 at 10:08 PM, Kevin Ballard wrote: > Well actually... > > LazyCollection right now has just this very behavior. The SubSequence of a > LazyCollection is a LazyCollection>. If you say > `[1,2,3].lazy.prefixUpTo(3).prefixUpTo(3)` you end up with a > LazyCollection>>. So the only

Re: [swift-evolution] [Review] Require self for accessing instance members

I know I’m responding to myself here, but a couple more points: 1. I’ve programmed in Objective-C for many years, and I don’t feel like I’ve used “self” all that often. 2. If we do enforce self, method cascading would mitigate some of the repetition. -Kenny > On Dec 18, 2015, at 9:52 PM, Ken

Re: [swift-evolution] [Review] Constraining AnySequence.init

Well actually... LazyCollection right now has just this very behavior. The SubSequence of a LazyCollection is a LazyCollection>. If you say `[1,2,3].lazy.prefixUpTo(3).prefixUpTo(3)` you end up with a LazyCollection>>. So the only way we can constrain SubSequence this way is by also making it poss

Re: [swift-evolution] [swift-evolution-announce] [Review] Require self for accessing instance members

Yes, to call the standalone foo, you'd call it on its module name: TheModuleOfFoo.foo() On Sat, Dec 19, 2015 at 6:52 AM, Kenny Leung via swift-evolution < swift-evolution@swift.org> wrote: > > * What is your evaluation of the proposal? > > +1 for it. > > > * Is the problem being addre

Re: [swift-evolution] [Review] Constraining AnySequence.init

Fair enough. I was thinking that it's better to err on the side of allowing flexibility, but there is something to be said for having slices of slices still be slices. My vague thought was that there might be some desire to have a slice be a type that wraps the thing being sliced, but I admit that

Re: [swift-evolution] [swift-evolution-announce] [Review] Require self for accessing instance members

> * What is your evaluation of the proposal? +1 for it. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. I feel it makes things more correct. > * Does this proposal fit well with the feel and direction of Swift? Yes. One of Swift’s g

Re: [swift-evolution] Proposal: Python's list, generator, and dictionary comprehensions

-1 from me. I find list comprehensions, on average, roughly as concise as methods on SequenceType, and generally harder to understand as soon as you have more than one collection. Jordan > On Dec 17, 2015, at 8:26 , Amir Michail via swift-evolution > wrote: > > Python examples: > > l = [x*x

Re: [swift-evolution] [Review] Constraining AnySequence.init

Hi Kevin, Thank you for your feedback! On Fri, Dec 18, 2015 at 3:13 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > > 2. One of the added constraints looks like > > > S.SubSequence.SubSequence == S.SubSequence > > > with a comment saying that ideally the set of constra

Re: [swift-evolution] [Review] Require self for accessing instance members

* What is your evaluation of the proposal? Against. I think cost of the proposed solution is greater than the benefit for a type of bug I have never encountered. * Is the problem being addressed significant enough to warrant a change to Swift? I think there are other ways to mitigate this ki

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution wrote: >> >> One potentially large downside is you can no longer look at a type >> declaration and find out how large it is. For example, I could define >> >> struct Foo { >> var x: Int >> } >> >> and it looks like a tiny struct,

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

Another option for handling this occurred to me - an "export list" in the lexical block that usually declares getters, setters, and will/didSet: class Thing { var property: String { [get, set] } } It's somewhat like a "capture list" syntax but in the context of the accessor declarations.

Re: [swift-evolution] [Proposal] Factory Initializers

I guess a better question here is, is it worth modifying the existing compiler/ABI behavior to explicitly allow returning instances from convenience initializers? Personally, while I prefer the use of return statements (especially because they're already used to return nil from failable initial

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

First of all great proposal, and thank you for trying to make it easier to write safe code with Swift. I feel like this proposal is more about human error than floating point error. I don't think this solves the precision issue. It makes it harder to use fmod, but doesn't stop people wanting to,

swift-evolution@swift.org

On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff wrote: > > On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko wrote: > There's also a possibility that we add 'out' parameters in the future, and > if 'inout' would be spelled '&', then we would need to find another sigil > for 'out'. > > We have multiple retu

swift-evolution@swift.org

I'd prefer `@inout` over `&x`. It more clearly communicates its function and annotations already exist on parameters so it reuses that concept and has a clear location. When using `@inout` I'm in favor of this change. Although I'd like to point out that with syntax highlighting `inout` the key

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

I was just talking about this kind of thing (I've updated the repo with up to 5-tuples) for times where you seq1 • seq2 • seq3 // 'Cartesian product' of a Cartesian product and a collection. Meant to help manage type explosion. public func •(lhs:Left, rhs:Right) -> [(A, B, Right. Generator.Elemen

swift-evolution@swift.org

Sent from my iPad > On Dec 18, 2015, at 8:21 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko wrote: >> >>> On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution >>> wrote: >>> For Swift 3, we're planning to phase out 'var' parameter

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Thanks for the clarification. Why is the compiler saying that the catch is not exhaustive when it is covering all the possible values of the enum? Is it to be able to catch future values added to the enum type? > On Dec 18, 2015, at 8:05 PM, David Owens II wrote: > > >> On Dec 18, 2015, at

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

> On Dec 18, 2015, at 5:46 PM, T.J. Usiyan wrote: > > Updated the library with that. The only downside that I can see is that > flattening, as I had always planned but finally bothered to do, has no way to > tell if the left tuple was the produce of a previous cartesian product > operation.

Re: [swift-evolution] [Proposal] Property behaviors

Sent from my iPad On Dec 18, 2015, at 8:11 PM, Stephen Christopher wrote: >> When do properties with behaviors get included in the memberwise initializer of structs or classes, if ever? Can properties with behaviors be initialized from init rather than with inline initialize

swift-evolution@swift.org

> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko wrote: > > On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords ar

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

I like `UnsafeReference` as the new name of the type and I think the basic API is clearer than with `Unmanaged`. The initializers are much better than the static methods and `take(Un)RetainedValue()` were certainly less than ideal method names. > On 18 Dec 2015, at 02:37, Dave Abrahams via swif

swift-evolution@swift.org

> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >> >> +1. Can you provide an example showing where you would place it though? > > Good question. Three options I see: > > - Before the label and binding names,

swift-evolution@swift.org

> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution > wrote: > > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords are valid argument labels. > With both of these changes pending, I have a hard time not readin

Re: [swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

> On Dec 18, 2015, at 5:38 PM, Brent Royal-Gordon > wrote: > >> I’m not sure how it affects your proposal, but I just want to point out that >> having things that are *only* statically dispatched is sometimes desirable. >> For example, Set equality is different from Collection equality, but

Re: [swift-evolution] [Proposal] Property behaviors

> > > When do properties with behaviors get included in the memberwise >> initializer of structs or classes, if ever? Can properties with behaviors >> be initialized from init rather than with inline initializers? >> > There’s a separate discussion that mentioned allowing better control of > which

swift-evolution@swift.org

On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > For Swift 3, we're planning to phase out 'var' parameters in functions, > and we're also making it so that language keywords are valid argument > labels. With both of these changes pending, I have

swift-evolution@swift.org

> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution > wrote: > > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords are valid argument labels. > With both of these changes pending, I have a hard time not readin

Re: [swift-evolution] [Proposal] Property behaviors

On Dec 18, 2015, at 3:56 PM, Kevin Ballard via swift-evolution wrote: > Ultimately, I would love to have non-copyable structs in Swift. But the only > way to really do that is to have references in the language (otherwise the > moment you call a method on a non-copyable struct, you've lost the

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

Updated the library with that. The only downside that I can see is that flattening, as I had always planned but finally bothered to do, has no way to tell if the left tuple was the produce of a previous cartesian product operation. Small price to pay and all that. Thanks for the insight! On Fri, D

swift-evolution@swift.org

> On Dec 18, 2015, at 5:33 PM, Dave Abrahams wrote: > >> >> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >>> >>> +1. Can you provide an example showing where you would place it though? >> >> Good quest

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > wrote: > > On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: >>> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: >>> On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: I think any storage-in-extensions proposal ou

Re: [swift-evolution] Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer

> On Dec 8, 2015, at 3:53 PM, Jordan Rose via swift-evolution > wrote: > >> >> On Dec 8, 2015, at 10:42, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 8, 2015, at 10:32 AM, Jacob Bandes-Storch >> > wrote: >>> >>> On

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: > > On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > >> I think any storage-in-extensions proposal ought to be a special feature > >> of classes; I would not support the ability to a

Re: [swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

> I’m not sure how it affects your proposal, but I just want to point out that > having things that are *only* statically dispatched is sometimes desirable. > For example, Set equality is different from Collection equality, but Set > conforms to Collection. If you write an algorithm over equat

swift-evolution@swift.org

> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >> >> +1. Can you provide an example showing where you would place it though? > > Good question. Three options I see: > > - Before the label and binding names,

swift-evolution@swift.org

> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: > > +1. Can you provide an example showing where you would place it though? Good question. Three options I see: - Before the label and binding names, where inout appears today, and where other argument modifiers like `@autoclosure` go: fu

swift-evolution@swift.org

+1. Can you provide an example showing where you would place it though? Sent from my iPad > On Dec 18, 2015, at 7:23 PM, Joe Groff via swift-evolution > wrote: > > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords are

Re: [swift-evolution] [Proposal] Property behaviors

Sent from my iPad > On Dec 18, 2015, at 7:05 PM, Stephen Christopher via swift-evolution > wrote: > > +1 for this proposal. I’m not clear on the syntax and need to take some time > exploring it though. > > As I read the code in the proposal, it once again blurred the lines for me > betwee

swift-evolution@swift.org

For Swift 3, we're planning to phase out 'var' parameters in functions, and we're also making it so that language keywords are valid argument labels. With both of these changes pending, I have a hard time not reading: func foo(inout x: Int) as an argument labeled `inout` instead of an unlabeled

Re: [swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

> On Dec 16, 2015, at 3:48 PM, Brent Royal-Gordon via swift-evolution > wrote: > > This proposal comes out of the threads "Proposal: Universal dynamic dispatch > for method calls” and “Proposal: Require explicit modifier for statically > dispatched extension methods”. I’m posting it now as a

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

That is… damned nice. I choose not to feel that bad about it… for reasons. On Fri, Dec 18, 2015 at 8:04 PM, Dave Abrahams wrote: > > On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution < > swift-evolution@swift.org> wrote: > > On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < >

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 3:40 PM, August Joki via swift-evolution > wrote: > > > > -August > >> On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote: >>> >>>

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

> On Dec 18, 2015, at 1:36 PM, Radosław Pietruszewski wrote: > > Interesting! I’d definitely be for some shortcut syntax here, as this seems > to be a very, very common pattern. Passing a function to, say, `map` is so > much easier and cleaner than passing a method in Swift — even though Swift

Re: [swift-evolution] [Review] Constraining AnySequence.init

Thanks for a review Kevin! > At the moment AnyCollection does not delegate calls to SequenceType protocol > methods to the underlying base sequence > > Presumably that should say AnySequence instead of AnyCollection, since the > rest of the proposal talks about AnySequence? Good catch. Althoug

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 18, 2015, at 4:38 PM, Ricardo Parada wrote: > > Hi David > > I started reading your proposal and I have a couple of questions. > > In the Enum Base ErrorType example you mentioned that it requires a "catch { > }" clause. However the code is already covering the two possible Enum va

Re: [swift-evolution] 3.0 if-var workaround construction question

> On Dec 18, 2015, at 5:53 AM, Brent Royal-Gordon via swift-evolution > wrote: > >>if var testStream = OutputStream(path: aPath) { >>print("Testing custom output", toStream: &testStream) > > What sticks out to me here is, why is OutputStream a value type at all? Does > it have som

Re: [swift-evolution] [Proposal] Property behaviors

+1 for this proposal. I’m not clear on the syntax and need to take some time exploring it though. As I read the code in the proposal, it once again blurred the lines for me between property and method. It often seems to me, at an intuitive / teaching level, a property is just semantic sugar for a

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

> On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution > wrote: > >> On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> With a Cartesian Product type [like >> this](https://github.com/griotspeak/CartesianProduct >>

Re: [swift-evolution] Final by default for classes and methods

Erica helped put together a survey at my request to try to collect some data on how often app developers write superclasses themselves vs classes that are effectively final (whether that is declared or not). The survey asks for opinions as well but I think the most interesting part will be data

Re: [swift-evolution] ternary operator ?: suggestion

Thanks for your support! I think parenthesis are preferred because braces are for bracketing lists of statements. Statements may or may not return values. Having the conditional on the inside of the parens helps to show the begging of the demux operator rather than a floating conditional whic

Re: [swift-evolution] Proposal: 0009 Require self for accessing instance members

Ambiguous in two cases: - when passing an argument (is this implied self, or implied type? — clashes with shortcut for enums etc) - starting the line with a dot now allows you to continue the method chain from the previous line. — Radek > On 19 Dec 2015, at 01:50, Paul Ossenbruggen via swift-

Re: [swift-evolution] [Proposal] Factory Initializers

> On Dec 18, 2015, at 3:20 PM, Riley Testut via swift-evolution > wrote: > > I’m not opposed to assigning to self directly in convenience initializers > (especially if there is already support for it in the ABI). My only concern > would be that it feels less “natural” to do so than to simply

Re: [swift-evolution] Proposal: 0009 Require self for accessing instance members

This may have been covered in the past but is there any reason why we can’t require use “.property”? It would work similar to the way you can use “.property” in enums. This would be terse, consistent with enum, and would help the call site be more explicit. This would be the same as self.proper

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Hi David I started reading your proposal and I have a couple of questions. In the Enum Base ErrorType example you mentioned that it requires a "catch { }" clause. However the code is already covering the two possible Enum values (OffBy1 and MutatedValue). Why is the "catch { }" required? I ty

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: >> I think any storage-in-extensions proposal ought to be a special feature of >> classes; I would not support the ability to add stored properties to structs >> in extensions, even from w

[swift-evolution] [Review] Require self for accessing instance members

* What is your evaluation of the proposal? Against. As self.an self.example, self.you can self.see how much self.harder it is to self.understand this self.sentence. We self.are self.not self.designed to self.scan words with self.self. in self.front of self.them. The problem with this proposal

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > I think any storage-in-extensions proposal ought to be a special feature of > classes; I would not support the ability to add stored properties to structs > in extensions, even from within the module. Oh that's an interesting idea. My immed

Re: [swift-evolution] Proposal - Allow properties in Extensions

+1 for "[giving] same-module extensions to do anything that can be done in the original type declaration", +1 for something akin to C#'s 'partial'. I've often wanted to organize my code for a single type within several files, grouping methods and properties by purpose, but have been stymied by both

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution > wrote: > On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote: >> >>> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> I only see the benefits on this. • We don

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

On Fri, Dec 18, 2015, at 03:40 PM, August Joki wrote: > >> On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift- >> evolution wrote: >>> On Dec 18, 2015, at 3:03 PM, Stephen Canon wrote

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> AFAIK there's no precedent today for extensions in the same module being >> able to do things that e

Re: [swift-evolution] [Proposal] Property behaviors

On Fri, Dec 18, 2015, at 07:18 AM, Michel Fortin wrote: > Le 17 déc. 2015 à 22:47, Kevin Ballard via swift-evolution > a écrit : > > > Good point. I'm also inclined to say that Michel's motivating example (of a > > property that requires going through a `synchronized` accessor) would be > > be

Re: [swift-evolution] ternary operator ?: suggestion

+1 I'd be very happy with your new proposal too. I still prefer sticking the value we're using as a key outside of the parens, but it's a minor quibble. Also I can't figure out if parens or curly braces are more appropriate. Does it make more sense for the expression to look like a tuple or a clos

Re: [swift-evolution] Proposal: Add .times method to Integer type

I think I'm -1 for this. It feels like something that should exist in a utility library rather than in the standard one. I do have an honest question that comes from ignorance rather than malice: has anyone actually used .times in ruby outside of the context of learning or testing? I've written a

Re: [swift-evolution] Proposal - Allow properties in Extensions

I’m really glad to see some discussion about this. I think it is an extremely worth while addition to Swift. Chris L. also thought it was a good idea, in general. If I get a chance I’ll make a formal request to consider it. Anyone else interested in offering it up, officially? Thanks, Kevin Ka

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

-August > On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution > wrote: > > On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote: >> >>> On Dec 18, 2015, at 3:03 PM, Stephen Canon >> > wrote: >>> >>> On Dec 18, 2015, at 5:57 PM

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution > wrote: > >> >> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Sounds like it could be super useful for libraries! >> >> How about we drop the quot

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution > wrote: > > On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote: >> >>> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> I only see the benefits on this. • We

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote: > >> On Dec 18, 2015, at 3:03 PM, Stephen Canon wrote: >> >> >>> On Dec 18, 2015, at 5:57 PM, Chris Lattner >>> wrote: >>> >>> On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution >> evolut...@swift.org> wrote:

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote: > > > On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution > > wrote: > > > >> I only see the benefits on this. > >>• We don't have to store all states in one file. States can be stored > >> separately.

Re: [swift-evolution] Proposal: Add .times method to Integer type

By the way and/or for all of you who like the idea of a .times method: I’ve just setup a library for features like this `times` method and implemented the suggested method there. Feel free to contribute code / provide feedback via that third party library (as suggested by Chris) here: https://g

Re: [swift-evolution] [Proposal] Factory Initializers

I’m not opposed to assigning to self directly in convenience initializers (especially if there is already support for it in the ABI). My only concern would be that it feels less “natural” to do so than to simply return a value from the initializer. That being said, I think that’s a very negligib

Re: [swift-evolution] Proposal: Add .times method to Integer type

-1 here. It provides almost no utility outside of "hello world" style sample code. Also this particular method is ambiguous, as people have already said (the word "times" can mean multiplication just as much as it can mean looping), and it also doesn't even make much sense when used with non-litera

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I only see the benefits on this. >> • We don't have to store all states in one file. States can be stored >> separately. So, we can write code in more composition style. >> • We can add new states to

Re: [swift-evolution] [Review] Constraining AnySequence.init

*# What is your evaluation of the proposal?* Overall it looks good. I haven't looked at the implementation of AnySequence before, but it sound fairly reasonable. A couple of minor nits: 1. The proposal motivation says > At the moment AnyCollection does not delegate calls to SequenceType > proto

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 3:03 PM, Stephen Canon wrote: > > >> On Dec 18, 2015, at 5:57 PM, Chris Lattner > > wrote: >> >> On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> Hi everybody — >>> >>> I’d like to

Re: [swift-evolution] Proposal - Allow properties in Extensions

I’d +1 this proposal for extensions existing in the same module as the class declaration. However, creating new properties for classes defined in other modules would likely involve side-table lookups, and my understanding is that it has some performance implications. In cases where you want

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 5:57 PM, Chris Lattner wrote: > > On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> Hi everybody — >> >> I’d like to propose removing the “%” operator for floating-point types. > > I support removing this - it i

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

I am not a numerics expert…… just have run into people using floats in banking and brokerage systems to do calculation with decimal numbers too many times in my life…. I even spent a whole night in a bank vault with the system on conversion trying to figure out why it was out by a single penny

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution wrote: > Hi everybody — > > I’d like to propose removing the “%” operator for floating-point types. I support removing this - it is actively harmful for a surprising operation like this to have such short and inviting syntax. As a

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

> On Dec 18, 2015, at 1:18 PM, Brent Royal-Gordon > wrote: > >> Also, while unambiguous, it’s a very low-level description of what’s >> happening, that doesn’t much help the user reading the documentation of a CF >> function to answer the “which one do I use?” question unless s/he’s already

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 1:19 PM, Craig Cruden via swift-evolution > wrote: > > http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/ > > > > >> On 2015-12-19, at 4:17:45, Craig Cruden > <

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

> On 18 Dec 2015, at 23:23, Dave Abrahams wrote: >> >> I think a second method à la dropFirst/Last/... that returns Void would be >> better at communicating intent and allows pop() to retain the warning. > > Those are non-mutating methods that don’t return Void, FWIW. Names to be > adjusted

Re: [swift-evolution] Proposal: Python's indexing and slicing

I would like to avoid what you currently have to do for iterating a subcontainer. for a in container[0..container.count-4] { // do something. } The slicing syntax would certainly help in these common situations. Maybe there are easy ways that I am not aware of. - Paul > On Dec 18,

Re: [swift-evolution] Proposal: Add .times method to Integer type

As far as I can remember it was never a goal of Swift to be a purely object-oriented language. Instead I can find expressiveness stated explicitly amongst the three main goals behind the language here: https://swift.org/about/#platform-support Theref

Re: [swift-evolution] Proposal: Python's indexing and slicing

> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution > wrote: > >> >> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Examples: >> >> >>> l=[1,2,3,4,5] >> >>> l[-1] >> 5 >> >>> l[-2] >> 4 >> >>> l[2:4] >> [3, 4] >> >>>

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

In the context of error handling, a "sub-enum" (a term I might use again to describe enum-backed enums) is an easy and scalable way to tailor the error reporting interface of a function. If David Owens II's annotated throws proposal

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

> On Dec 18, 2015, at 2:01 PM, Janosch Hildebrand via swift-evolution > wrote: > > I am also strongly in favor of this proposal. > > There are probably enough valid use cases for a @suppress_unused_warning but > personally I don't think pop() is a great example. > > I think a second method à

Re: [swift-evolution] Proposal: Add .times method to Integer type

I don’t agree with this on the grounds that it isn’t very object-oriented. That is, it does not conform with what one usually associates with an integer. A number has certain intrinsic properties: 5 is greater than 4 but less than 6. If you’re a synesthete, it may have the color blue. But I neve

Re: [swift-evolution] do try catch?

> On Dec 7, 2015, at 8:30 PM, Liam Butler-Lawrence via swift-evolution > wrote: > Hi Kame, > > Thanks for the work you put into this! I’ll give my thoughts on each proposed > syntax: > >> // First syntax: >> guard let >> bar = bar, // Has to be non-nil >> try foo("Hello"),

Re: [swift-evolution] Readwrite reflection in Swift

> > Also consider alternatives to the use cases you described—mocking and data > modeling can also be accomplished by compile-time code generation, and by > features like type providers that supply external type information to the > compiler. Runtime reflection is definitely useful in many cases, b

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

Not that it seems highly contested, but +1 from me as well. Jacob On Fri, Dec 18, 2015 at 2:01 PM, Janosch Hildebrand via swift-evolution < swift-evolution@swift.org> wrote: > I am also strongly in favor of this proposal. > > There are probably enough valid use cases for a @suppress_unused_warni

Re: [swift-evolution] ternary operator ?: suggestion

All, I think, I finally might have the answer to improving ternary, with such a bold statement come some pretty high expectations but I think, I might actually have done it this time :-) I am calling it the Demux Expression, it builds on the benefits of ternary and switch while improving on th

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

I am also strongly in favor of this proposal. There are probably enough valid use cases for a @suppress_unused_warning but personally I don't think pop() is a great example. I think a second method à la dropFirst/Last/... that returns Void would be better at communicating intent and allows pop(

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

Er, typo in the first sentence! I meant to say: I was quite surprised to learn that it’s possible to create Swift strings that contain things other than valid Unicode characters. > On Dec 18, 2015, at 3:47 PM, Paul Cantrell via swift-evolution > wrote: > > I was quite surprised to learn that

Re: [swift-evolution] Proposal: Add .times method to Integer type

I’d be in favor of deferring this until other discussions about the ability to return/break/continue from closures play out. With that in place, there’s even the notion that for…in could be replaced by a library function. At that point, 5.times, or repeat(5) as a library call, would look a lot m

  1   2   3   >