Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[offtopic for "A New Model for Collections and Indices"] Just wanted to add my 2 cents to this new naming guidelines proposal that @Dave pointed to: "Update API Naming Guidelines and Rewrite Set APIs Accordingly" https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-ap

Re: [swift-evolution] [Proposal] Custom operators

Антон Жилин: > No new suggestions have come in 2 days, and so I have created a pull request! > https://github.com/apple/swift-evolution/pull/253 1. Assignment operators in Swift 2.2 have an `assignment` keyword: infix operator += { associativity right precedence 90 assignment } 2. If assig

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

Totally agreed with you guys, for me the matter question here is: Why should we care about language details instead what the app really have to do? Keeping in mind that kind of stuff doesn't help, the focus should be in their functionalities and all that could be done to get handy and keep a cle

Re: [swift-evolution] What about a VBA style with Statement?

Yes, I agree, that "implicit" "with", where we can't say if method belongs to the target instance or not, is very bad idea. I strongly agains it. But the proposal is for "explicit" "with", where it is clear what method/property belongs to target instance, and which don't. So most of your notes

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

As I understand, currently Range can not be greater than . So we just can't use 0..<-2. And I don't think we should implement such thing as it is not very explicit about what we are expecting. On 14.04.2016 0:29, Dave Abrahams via swift-evolution wrote: That approach makes sense too. But the

[swift-evolution] [Random Thought] Optional Protocol Methods + Mixins

Hi Everyone, I have been mulling over the problems of optional protocol methods and (separately) the mixin / diamond problem over in my head for a week or so now, and I wonder if they might have a common solution. The main philosophical dispute seems to be around what we call the "system image

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > [offtopic for "A New Model for Collections and Indices"] > > Just wanted to add my 2 cents to this new naming guidelines proposal that > @Dave pointed to: > "Update API Naming Guidelines and Rewrite Set APIs Accordingly

Re: [swift-evolution] What about a VBA style with Statement?

> On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution > wrote: > > The biggest advantage of the with pattern IMO is Cocoa initializers. It > provides a more unified > initialization scope. Instead of: > > let questionLabel = UILabel() > questionLabel.textAlignment = .Center > questionLa

[swift-evolution] Implementing a protocol with default implementations

Optional protocols are implemented with 1> protocol P { 2. func bar() 3. } 4. extension P { 5. func bar() { 6. // do nothing 7. } 8. } but all bets are off when I'm using this like so 9> struct S {} 10. extension S : P { 11. func baz() { 12. print(

Re: [swift-evolution] [Proposal] Custom operators

Just want to make sure the pull request is noticed. The proposal is ready for merge. Note that we can now "squash and merge" on Github. - Anton ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evol

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

+1. Completely agree with what Eugene said. On Thu, Apr 14, 2016 at 1:14 AM Eugene Gubin via swift-evolution < swift-evolution@swift.org> wrote: > I like this idea. I think, if we could use `self` to access instance of > self, we should be allowed to use `Self` to access type of self. > > 2016-04-

Re: [swift-evolution] What about a VBA style with Statement?

Agree, that we can already use some hacks(IMO) to have some kind of what we need. Actually, we already discussed some variants : method "with" in extension to type and global generic function "with". Each of them has disadvantages in compare to "with" language construction. In your example you n

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

Pull request updated with just the rename. This amounted to basically saying "Self" will replace "self.dynamicType" and eliminate an outlier case for a keyword using camel case. I did not include any discussion of generalizing protocol existentials. I can add in a future directions section if y

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I don’t particularly like these name changes. I would even go as far as saying that these recent discussions about renaming flatten, map, filter, reduce has made me question the original Swift 3 API renaming. What I mostly like about the current (2.2) naming is that the non-mutating version is

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

+1, I also support. We already have Self in meaning of dynamicType as result of method, for example: class A { func some()->Self { //print(self.dynamicType) // btw: if we uncomment this - will get run-time error wtf?? return self } } class B:A { } var aa = B() print(

[swift-evolution] [Pitch] Unifying init parameters with properties

This is a common pattern for initialisers at the moment: class Foo { let foo : String let bar : String let barCount : Int let baz : Int init(foo: String, bar: String, baz: Int) { self.foo = foo self.bar = bar self.baz = baz barCount = bar.characters.count } } This involves a lot of

Re: [swift-evolution] What about a VBA style with Statement?

Very strong -1 to implicit 'with'. Javascript tried this and it was a disaster, and eventually banned in strict mode. It tends to make compilation and optimization of a variable within a 'with' block impossible, as it could refer to the fields of any object, or even a method call behind protocol

[swift-evolution] Proposal: conversion protocol naming conventions

I was reading the document and was wondering if it might make sense to look into using definitions rather than conventions: public protocol LiteralCreatable { associatedtype LiteralType init(literalValue : LiteralType) } public protocol NilLiteralConvertible : LiteralCreatable { assoc

Re: [swift-evolution] What about a VBA style with Statement?

> (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is implicitly > returned in absence of a return value and can be ignored. I'm a big fan of returning self — its much more useful than void… But it seems the Swift-community doesn't like method chaining. _

[swift-evolution] [Proposal] Shadowing imported functions

As promised, I've created a proposal to add @shadowing attribute. Link to the proposal: https://github.com/Anton3/swift-evolution/blob/shadowing-imported-functions/proposals/-shadowing-imported-functions.md Example: // Imported function (implicit declaration)func dispatch_sync(queue: dispatc

Re: [swift-evolution] [Proposal] Shadowing imported functions

As a side effect, we will be able to purge IUO from Swift abolutely, completely. And add a rule that we can shadow Optional parameter with T for some T. But it is the theme of a separate proposal. - Anton 2016-04-14 18:28 GMT+03:00 Антон Жилин : > As promised, I've created a proposal to add @sha

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

(re-added swift-evolution) I would think so. It's an abbreviation of a given init function, so you would call other self.init() or super.init() functions normally. Saves on complication. Alternatively, perhaps you could do this: init(self.foo: String, super.bar: String, super.baz: Int) as an a

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

There has been a long debate about something similar: [Proposal Draft] Flexible memberwise initialization Afair there has been a general agreement that the current boilerplate is ugly, but all suggested alternatives had flaws as well

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

Don't think idea with super.bar etc in init is good, as we should explicitly call super.init() with needed parameters. So, I see this in such a way: init(self.foo: String, bar: String, baz: Int) super.init(bar: bar, baz: baz) ... } The only way we can specify values for super.init in our i

Re: [swift-evolution] [Proposal] mapValues

on Wed Apr 13 2016, Andrew Bennett wrote: > I'm wondering if `Dictionary.Element`should be `Value`, > instead of `(Key,Value)`. I think(?) it's fairly unprecedented. Python sets the *opposite* precedent, FWIW (a dict is a sequence of its keys). One possible upside is that Dictionary becomes

[swift-evolution] TreeLiteralConvertible

In Swift, we cannot compile: _ = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] The reason for the compile-time error is that we are not in fact creating an array, but a tree – a more general structure of which arrays are only a special case. Given the well-deserved and growing reputation of Swift,

Re: [swift-evolution] What about a VBA style with Statement?

For what it's worth, I left vba behind a long time ago and I have some bad memories of what I saw in these with blocks: people writing a page worth of code where only a couple line were actually referencing .x. In the end, they thought it made their code look cool when I just saw it as a rea

Re: [swift-evolution] What about a VBA style with Statement?

On Thu, Apr 14, 2016 at 8:23 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > > (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is > implicitly > > returned in absence of a return value and can be ignored. > I'm a big fan of returning self — its much more u

[swift-evolution] TreeLiteralConvertible

In Swift, we cannot compile: _ = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] The reason for the compile-time error is that we are not in fact creating an array, but a tree – a more general structure of which arrays are only a special case. Given the well-deserved and growing reputation of Swift,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, Shawn Erickson wrote: > On Wed, Apr 13, 2016 at 4:45 PM Dave Abrahams via swift-evolution > wrote: > > Updated proposal: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > I like the use of `location(...)` instead

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

So I suggest to discuss some "middle" solution: not too complex, but that will improve our live. I believe this (in subject) proposal don't require a lot of changes in Swift, it seems more like sugar Compiler "just" can replace init (self.a: Int, self.b: String) { //... } to init (a: Int,

[swift-evolution] [Accepted] SE-0057: Make unsafe pointer nullability explicit using Optional

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md The review of SE-0057 "Importing Objective-C Lightweight Generics" ran from Mar 31…Apr 5, 2016. The proposal has been *accepted*: This proposal only received light commentary from the c

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

on Thu Apr 14 2016, "Vladimir.S" wrote: > As I understand, currently Range can not be greater than > . So we just can't use 0..<-2. And I don't think we should > implement such thing as it is not very explicit about what we are > expecting. > > On 14.04.2016 0:29, Dave Abrahams via swift-evolut

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 14, 2016, at 10:42 AM, Jonathan Tang via swift-evolution > wrote: > > On Thu, Apr 14, 2016 at 8:23 AM, Tino Heth via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is > > implicitly > > returned in ab

Re: [swift-evolution] [Accepted] SE-0057: Make unsafe pointer nullability explicit using Optional

Has there been a mix-up with the title of the proposal in the subject line? On Thu, Apr 14, 2016 at 5:59 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md > > Th

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, plx wrote: >> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Apr 13 2016, plx wrote: >> > >>>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>>on Tue Apr 12 2016, plx >>> wrote: >>

Re: [swift-evolution] TreeLiteralConvertible

Well, actually we can compile : var zz : [Any] = [[Int](), 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] [] - is empty array of unknown type, I think this is why you can't compile. We need good language tools to process such kind of array, I agree with you. As for your proposal.. I have no idea if thi

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, plx wrote: > On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Apr 13 2016, plx > wrote: > > Seriously, just because Swift has Optionals and they're useful for > safety in some scenarios (compared with allowing everyt

Re: [swift-evolution] What about a VBA style with Statement?

Can't agree with you. As you see from this topic, many of us use the "with" feature by using workarounds/hacks. Those, who don't use such "with" feature - can produce even more bugging code(copy-paste,wrong editor's code completion suggestion). So, I think this is "good" feature, not just cool/

Re: [swift-evolution] TreeLiteralConvertible

Thanks for the comment, Vladimir. > On 14 Apr 2016, at 18:14, Vladimir.S wrote: > > Well, actually we can compile : > > var zz : [Any] = [[Int](), 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] > Sure. I just wasn’t sure it was worth mentioning (it was a long post anyway): annotating the variable wit

Re: [swift-evolution] TreeLiteralConvertible

> On 14 Apr 2016, at 13:26, Milos Rankovic via swift-evolution > wrote: Please disregard this, the earlier of the two posts with the subject “TreeLiteralConvertible". I appears it escaped me while composing. With embarrassment and apologies, milos_

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 14, 2016, at 7:39 PM, Vladimir.S via swift-evolution > wrote: > > > Can't agree with you. > > As you see from this topic, many of us use the "with" feature by > using workarounds/hacks. > > Those, who don't use such "with" feature - can > produce even more bugging code(copy-paste,wr

Re: [swift-evolution] TreeLiteralConvertible

Hey, Milos! Can you please give us a few real-world examples where initializing a nontrivial tree-like data structure in code would be useful? It's an honest question — I have never felt the need in my life, and I always preferred to move the data into something like a bundled json or CSV, rath

Re: [swift-evolution] What about a VBA style with Statement?

>> I also like the idea of a dedicated method-cascading operator, like what >> Dart has. It eliminates the need for a programmer to explicitly remember to >> 'return self' at the end of a chainable method. Not sure how well it'd >> integrate with SE-0047 (@discardableResult) though. > > Metho

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 8:23 PM, Andrey Tarantsov via swift-evolution > wrote: > > Hey, Milos! > > Can you please give us a few real-world examples where initializing a > nontrivial tree-like data structure in code would be useful? > > It's an honest question — I have never felt the need in m

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

Hi All. Aeons ago, I was on the team that invented key paths. There were some pretty major performance issues: - the key path had to be separated into its individual components, requiring processing time and generating a bunch of garbage - the obvious thing to do would have been to parse the k

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

-1 from me. To me this is not *obvious* as to what "Self" it means. And it seems possible to run into this: self.someClass.Self Just looks confusing to me. What's wrong with using "Type" or something more obvious? Sent from my iPad > On Apr 14, 2016, at 10:28 AM, Vladimir.S via swift-evoluti

Re: [swift-evolution] TreeLiteralConvertible

Hi Andrey and Laurent, > On 14 Apr 2016, at 19:23, Andrey Tarantsov wrote: > > Can you please give us a few real-world examples where initializing a > nontrivial tree-like data structure in code would be useful? > > It's an honest question — I have never felt the need in my life, and I always

Re: [swift-evolution] [Accepted] SE-0057: Make unsafe pointer nullability explicit using Optional

Yep, resent, sorry about that. -Chris > On Apr 14, 2016, at 10:03 AM, Xiaodi Wu wrote: > > Has there been a mix-up with the title of the proposal in the subject line? > On Thu, Apr 14, 2016 at 5:59 PM Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Proposal Link

[swift-evolution] [Accepted] SE-0057: Importing Objective-C Lightweight Generics

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md The review of SE-0057 "Importing Objective-C Lightweight Generics" ran from Mar 31…Apr 5, 2016. The proposal has been *accepted*: This proposal only received light commentary from the c

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

on Wed Apr 13 2016, Joe Groff wrote: > It's been pitched before, but I don't think we've had a dedicated > thread to this idea. Erica has proposed making `Self` generally > available within methods in types to refer to the dynamic type of the > current receiver. One could think of `Self` as a sp

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

+1 can’t wait for the Generics 4.0: typealias StringDictionary = Dictionary Parameterized extensions +++ func containsAll(elements: S) -> Bool where Sequence.Iterator.Element == Element ++ Higher-kinded types +++ Generalized existentials Generic protocols The Con

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

Dave Abrahams via swift-evolution writes: > > If I thought extreme concision was important for this application, I'd be > proposing something like > > for x in 0.0..<20.0//1.3 {} > > but personally, I don't, > And that is why exactly? The For-loop is at the very core of the language and one

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> On Apr 14, 2016, at 12:29 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, Joe Groff wrote: > >> It's been pitched before, but I don't think we've had a dedicated >> thread to this idea. Erica has proposed making `Self` generally >> available within methods in types

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

I've just updated the proposal draft adding this new approach as an "alternative considered", hope it conforms to what we've discussed so far: https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md#alternatives-considered I'll wait

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 12:01 PM, Milos Rankovic via swift-evolution > wrote: > Hi Andrey and Laurent, > >> On 14 Apr 2016, at 19:23, Andrey Tarantsov > > wrote: >> >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I do not understand why we can’t do type(self) or even #type(self) Personally, I find .Self business to be quite confusing and idiosyncratic. Having a generic #type() directive would be a general improvement for the language design and it would also open up future possibilities such as e

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

on Thu Apr 14 2016, Hans Huck wrote: > Dave Abrahams via swift-evolution writes: > >> >> If I thought extreme concision was important for this application, I'd be >> proposing something like >> >> for x in 0.0..<20.0//1.3 {} >> >> but personally, I don't, >> > And that is why exactly? The

Re: [swift-evolution] TreeLiteralConvertible

Hi John, > On 14 Apr 2016, at 21:09, John McCall wrote: > > I mean, you could just make your Tree type implement all the individual > literal-convertible protocols. It does sound like something like that should be doable, but it isn’t. The literal-convertible protocols only require one initia

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 1:34 PM, Milos Rankovic > wrote: > Hi John, > >> On 14 Apr 2016, at 21:09, John McCall > > wrote: >> >> I mean, you could just make your Tree type implement all the individual >> literal-convertible protocols. > > It does sound like something l

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> On Apr 14, 2016, at 1:11 PM, Taras Zakharko wrote: > > I do not understand why we can’t do > > type(self) > > or even > > #type(self) > > Personally, I find .Self business to be quite confusing and idiosyncratic. > Having a generic #type() directive would be a general improvement for the

Re: [swift-evolution] TreeLiteralConvertible

> On 14 Apr 2016, at 21:36, John McCall wrote: > > No, you just need Tree to conform to both ArrayLiteralConvertible and > IntegerLiteralConvertible, and it implements the latter by building a Value > out of it. You mean this: public enum IntTree { case Leaf(Int) case Branche

Re: [swift-evolution] What about a VBA style with Statement?

> As a plus, it makes code easier to write, sometimes; or at least it seems so. > On the other hand, I think it makes code harder to comprehend. A `with` > statement introduces a new scope in which it is not obvious what exactly > happens. For example: > > with(someObject) { >foo() > } > >

[swift-evolution] Question about SE-0057 "Importing Objective-C Lightweight Generics"

https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md How can Swift know if an Objective-C class implements +/- classForGenericArgumentAtIndex: at compile time? Does it look at the object code? Or does it look at the header file? Or maybe there is a third

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I do not think that I was conflating these two aspects. Using #type(self) would return the particular type of the current instance (dynamic type) while using #type(A.var) would return the declared (static) type of the property. Now, let a = A() #type(a.var) would again return the actual (

[swift-evolution] [Accepted] SE-0048: Generic Type Aliases

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The proposal received overwhelmingly positive feedback and has now been implemented for Swift 3. - Doug ___

Re: [swift-evolution] TreeLiteralConvertible

> No, you just need Tree to conform to both ArrayLiteralConvertible and > IntegerLiteralConvertible, and it implements the latter by building a Value > out of it. That not only doesn't work if your type isn't a LiteralConvertible, it also doesn't work if you want to build a literal with variabl

Re: [swift-evolution] TreeLiteralConvertible

I think a better solution than just adding a TreeLiteral (and the accompanying TreeLiteralConvertible protocol) would be to allow user-defined literal types using regex (or something similar). This would not only allow for tremendous flexibility, but it’d remove some compiler magic as well. The

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:03 PM, Milos Rankovic > wrote: >> On 14 Apr 2016, at 21:36, John McCall > > wrote: >> >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> ou

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon > wrote: >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> out of it. > > That not only doesn't work if your type isn't a LiteralConvertibl

Re: [swift-evolution] Crypto routines as part of the core library

Why would it need to be built into the language proper instead of the core libraries? I am not too familiar with the core libraries, but perhaps swift-corelibs-dev is the more appropriate mailing list here? > On Apr 13, 2016, at 7:2

Re: [swift-evolution] Crypto routines as part of the core library

Core libraries would be a great place, I just think this is a huge oversight in the language itself. I don’t think libraries found out on Github should be trusted, I think crypto should be done in an organized effort to ensure that the implementations are proper. Travis Beech | Principal Develo

Re: [swift-evolution] Crypto routines as part of the core library

> On Apr 14, 2016, at 2:36 PM, Travis Beech > wrote: > > Core libraries would be a great place, I just think this is a huge oversight > in the language itself. I don’t think libraries found out on Github should be > trusted, I think crypto should be done in an organized effort to ensure that

Re: [swift-evolution] TreeLiteralConvertible

The topic’s come up before. I’m in favor of it, but IIRC there are two problems that need to be resolved first: (I *think* I’m remembering this correctly… don’t quote me on this…) First, it can cause the type-checker to become “pathological”. Second, it can cause some *very* unexpected behavior

Re: [swift-evolution] Crypto routines as part of the core library

It should be provided by Swift, not some unknown developer out on Github, no matter how good his\her credentials are. I see core libraries as part of the language runtime. If you look at other modern languages such as Java, crypto is there out of the box, you don’t have to do anything extra to g

Re: [swift-evolution] TreeLiteralConvertible

>> extension Tree: LiftingConvertible { >> init(lifting value: Value) { >> self = .leaf(value) >> } >> } > > Another name for this feature is "user-defined implicit conversions". This is absolutely a form of user-defined implicit conversion

Re: [swift-evolution] Crypto routines as part of the core library

> On Apr 14, 2016, at 2:42 PM, Travis Beech > wrote: > > It should be provided by Swift, not some unknown developer out on Github, no > matter how good his\her credentials are. I see core libraries as part of the > language runtime. If you look at other modern languages such as Java, crypto

Re: [swift-evolution] Crypto routines as part of the core library

Thanks Michael for the input. I realized that after your last response I was indeed mixing terms. I will post up on the swift-corelibs-dev list. Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209) 535-5357 Optimizing Operations for Mobile and Distributed Systems From: mailto:mil

Re: [swift-evolution] Crypto routines as part of the core library

Great! I will watch that thread as it’s something I’m also interested in knowing more about. Thanks for bringing it up! > On Apr 14, 2016, at 2:51 PM, Travis Beech > wrote: > > Thanks Michael for the input. I realized that after your last response I was > indeed mixing terms. I will post up o

[swift-evolution] [Accepted] SE-0049: Move @noescape and @autoclosure to be type attributes

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md Hello Swift Community, The review of SE-0049 "Move @noescape and @autoclosure to be type attributes” ran from March 28...31, 2016. The proposal is accepted for Swift 3. Feedback

Re: [swift-evolution] TreeLiteralConvertible

Hi John and Brent, > On 14 Apr 2016, at 22:22, John McCall wrote: > > multiple-conformance idea doesn't work The idea is not multiple-conformance (or overloading), but multiple (two) initialisers required by the literal-convertible protocols: protocol TreeLiteralConvertible { associ

Re: [swift-evolution] Question about SE-0057 "Importing Objective-C Lightweight Generics"

> On Apr 14, 2016, at 2:06 PM, Michael Peternell via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md > > How can Swift know if an Objective-C class implements +/- > classForGenericArgumentAtIndex: at compile time? Doe

Re: [swift-evolution] SE-0063: SwiftPM System Module Search Paths - JSON output of install dependencies of a package

> According to the proposal: > > We do not wish to provide a flag to automatically install dependencies via > > the system packager. ... Instead we can provide JSON output that can be > > parsed and executed by some other tooling developed outside of Apple. > > This feature could be crucial for

Re: [swift-evolution] SE-0063: SwiftPM System Module Search Paths - JSON output of install dependencies of a package

On 2016-04-14, at 15.04, Max Howell via swift-evolution wrote: > >> According to the proposal: >> > We do not wish to provide a flag to automatically install dependencies via >> > the system packager. ... Instead we can provide JSON output that can be >> > parsed and executed by some other too

[swift-evolution] [Accepted] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md Hello Swift Community, The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance Member Implementations” ran from March 31...April 5, 2016. The proposal is accepted for Swift 3. We we

Re: [swift-evolution] Crypto routines as part of the core library

Travis / Michael, +1 on built-in support for Crypto libraries in swift-corelibs. On 14 April 2016 at 22:52, Michael Ilseman via swift-evolution wrote: > Great! I will watch that thread as it’s something I’m also interested in > knowing more about. Thanks for bringing it up! > > On Apr 14, 2016

[swift-evolution] [Accepted] SE-0062: Referencing Objective-C key-paths

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md Hello Swift Community, The review of SE-0062 "Referencing Objective-C key-paths” ran from April 7...12, 2016. The proposal is accepted, with one adjustment to the handling of collections: rather

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0062: Referencing Objective-C key-paths

> On Apr 14, 2016, at 3:48 PM, Douglas Gregor wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md > > > > Hello Swift Community, > > The review

[swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md Hello Swift Community, The review of SE-0064 "Referencing the Objective-C selector of property getters and setters” ran from April 7...12, 2016. The proposal is accepted. Feedback was light

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 14, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > wrote: >>> >>> No, you can't, at least not usefully. An Index that's at the end of one >>> collection is in the middle of another, or with a suitably-modified version >>> of the same collection. >> >> Sure, in certain concr

Re: [swift-evolution] What about a VBA style with Statement?

On Apr 14, 2016, at 2:55 PM, Brent Royal-Gordon via swift-evolution wrote: > * The ability to name a closure parameter `self`, which would make bare > method calls be directed to that parameter. Could this would this tie into the weak-strong dance? And if so, how? -- E ___

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

> On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution > wrote: > Please elaborate. How could > > for i in (1...10).by(3) > > possibly be misinterpreted? > (1..<11), (4..<14), (7..<17)... -- E ___ swift-evolution mailing list swift-evoluti

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 14, 2016, at 12:30 PM, Andrey Tarantsov wrote: > >>> I also like the idea of a dedicated method-cascading operator, like what >>> Dart has. It eliminates the need for a programmer to explicitly remember >>> to 'return self' at the end of a chainable method. Not sure how well it'd >

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

Dave Abrahams via swift-evolution writes: > > > on Thu Apr 14 2016, Hans Huck swift.org> wrote: > > > Dave Abrahams via swift-evolution ...> writes: > > > >> > >> If I thought extreme concision was important for this application, I'd be > >> proposing something like > >> > >> for x in 0.

[swift-evolution] [Proposal draft] Enhanced floating-point protocols

Enhanced floating-point protocols Proposal: SE- Author(s): Stephen Canon Status: Awaiting review Review manager: TBD

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

+1 nice addition -- Howard. On 14 April 2016 at 11:41, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > It's been pitched before, but I don't think we've had a dedicated thread > to this idea. Erica has proposed making `Self` generally available within > methods in types to

Re: [swift-evolution] What about a VBA style with Statement?

> Le 14 avr. 2016 à 09:49, Vladimir.S via swift-evolution > a écrit : > > Agree, that we can already use some hacks(IMO) to have some kind of what we > need. > Actually, we already discussed some variants : method "with" in extension to > type and global generic function "with". Each of them

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

Erica Sadun via swift-evolution writes: > > > > On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution swift.org> wrote: > > Please elaborate. How could > > > > for i in (1...10).by(3) > > > > possibly be misinterpreted? > > > > (1..<11), (4..<14), (7..<17)... > Or (3..<30)? :) With

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

What about "strideby" Brandon > On Apr 14, 2016, at 8:57 PM, Hans Huck via swift-evolution > wrote: > > Erica Sadun via swift-evolution writes: >> >> >>> On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution > swift.org> wrote: >>> Please elaborate. How could >>> >>> for i in (1...1

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

> for i in p1.. > as syntactic sugar for and internally mapped to > > for i in (p1.. > Best of both worlds? Look. It is very, very unlikely that you will get people to add syntactic sugar *just* for striding and *just* for the for loop. If this: for i in (1..<10).striding(by: 2) { … }

  1   2   >