[swift-evolution] Move where clause to end of declaration

Hello swift-evolution, I took the pitch originally from Developer to move the where clause out of the generic parameter list, with improvements brought up by Pyry Jahkola, and wrote a proposal for it. I opened a Pull Request, but if anybody wants to bring some modifications to it before it is m

Re: [swift-evolution] Move where clause to end of declaration

Hi there, just wanted to let you know I have a name! It's unfortunate that the mailing list won't accept the update I've made (this has been the 3rd-ish time I've tried). ~Robert Widmann 2016/05/02 3:16、David Hart のメッセージ: > Hello swift-evolution, > > I took the pitch originally from Develop

Re: [swift-evolution] Move where clause to end of declaration

I'll update the proposal ASAP :) Btw, wasn't sure if you wanted to be cited as co-author because I did not have your express approval, but I thought it was the right thing to do. Was in a bit in a hurry to send the Pull Request before going to work. > On 02 May 2016, at 09:20, Developer wrote:

Re: [swift-evolution] Move where clause to end of declaration

Name updated: https://github.com/apple/swift-evolution/pull/281 > On 02 May 2016, at 09:39, David Hart wrote: > > I'll update the proposal ASAP :) Btw, wasn't sure if you wanted to be cited > as co-author because I did not have your express approval, but I thought it > was the right thing to d

Re: [swift-evolution] Move where clause to end of declaration

Thank you for the effort David, this is great! Considering this example: > On 02 May 2016, David Hart wrote: > > For example, here is the same function declaration (…) after the change: > func anyCommonElements(lhs: T, _ rhs: U) > -> Bool where > T.Generator.Element: Equatable, > T.Ge

Re: [swift-evolution] Move where clause to end of declaration

Yep, I made a pull request already, but I still need to fix the thread link once games becomes available again. I’ll add an example about the current proposal allowing you to move the inheritance constraints out :) It’s good to have the choice. > On 02 May 2016, at 10:11, Pyry Jahkola wrote: >

Re: [swift-evolution] Move where clause to end of declaration

Hello You have an extra where dangling in the from example Dany > Le 2 mai 2016 à 03:16, David Hart via swift-evolution > a écrit : > : > func anyCommonElements T.Generator.Element: Equatable, > T.Generator.Element == U.Generator.Element>(lhs: T, _ rhs: U) -> Bool > where > { > .

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On 1 May 2016, at 09:12, Антон Жилин wrote: > > Pattern binding for optionals will look like: > > if let x? = y { … } Would take a little getting used to, but I think I’d be fine with it, as the way things are now is inconsistent with regular assignments (which remain optional). My only c

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

So I’m pretty late to the discussion here, but my question is; do we really want to encourage large blocks of text in code? They tend to bloat things, especially if they’re not used very often, and even if they are, any large chunk of text can be loaded from file and cached if (and when) necessa

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

I’ve been trying to keep up with this thread and this crossed my mind too. Of course, we don’t want to rule out multi-line strings because of readability and flexibility (Python “”” or Markdown’s ```…``` would be my vote). However, a built-in tempting engine like Mustache would be progressive an

Re: [swift-evolution] [Idea] Remove optional pattern binding

Currently, if case let x? = y { ... } is a sugared version of: if case let .some(x) = y { ... } which is in turn a sugared version of: if case .some(let x) = y { ... } Pattern matching in `if` works like this: left hand side of `=` contains supposed structure of value at right hand side. If w

Re: [swift-evolution] Move where clause to end of declaration

Nice catch! > On 02 May 2016, at 11:58, Dany St-Amant via swift-evolution > wrote: > > Hello > > You have an extra where dangling in the from example > > Dany > > Le 2 mai 2016 à 03:16, David Hart via swift-evolution > mailto:swift-evolution@swift.org>> a écrit : > : >> func anyCommonEleme

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

> I'm having trouble getting the `e` modifier to work as advertised, at least > for the sequence `\\`. For example, `print(e"")` prints two backslashes, > and `print(e"\\\")` seems to try to escape the string literal. I'm currently > envisioning `e` as disabling *all* backslash escapes, so

[swift-evolution] throw expressions in ternary operators

I remember discussing something like this in swift-evolution but can’t find it. I was wondering if it was worth a proposal or not. When constructing objects from dictionary of values, I often write the parsing of optional values as such: age = try dictionary["age"].flatMap { if let age

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

> So I’m pretty late to the discussion here, but my question is; do we really > want to encourage large blocks of text in code? It's not written up, but it has occurred to me that, rather than having `"""` strings or even heredocs for large chunks of text, we might want something which puts the

Re: [swift-evolution] throw expressions in ternary operators

But this causes a compilation error. Don’t you think the ternary operator should allow an expression that throws on the right hand side? For one, ?? is not a ternary operator, ?: is. But I guess it’s just a misspelling.  Anyway, there’re the throwing versions of the ?? operator: public func ??(

Re: [swift-evolution] throw expressions in ternary operators

Correct, it is not ternary, just a slip of my mind :) > let age = try dictionary["age"].flatMap { elem in > try elem as? Int ?? { throw Error() }() > } I didn’t know this workaround worked. Cool! Can somebody from the core team tell us if it not supporting throw directly is a bug or an inten

Re: [swift-evolution] throw expressions in ternary operators

Correct, it is not ternary, just a slip of my mind :) I have a great amount of understanding for that, I find `nil coalescing operator` name simply impossible to remember :) I didn’t know this workaround worked. Cool! Can somebody from the core team tell us if it not supporting throw directly

[swift-evolution] Should we rename "class" when referring to protocol conformance?

I was just thinking that: protocol Foo : reference {} might be more to the point than: protocol Foo : class {} I know that it’s currently a moot point because classes are the only* reference-semantics type of type in Swift, but it’s conceivable that there might some day be others. Anyway, I’m no

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

Inline Regards LM (From mobile) > On May 2, 2016, at 2:23 PM, John Holdsworth wrote: > > >> I'm having trouble getting the `e` modifier to work as advertised, at least >> for the sequence `\\`. For example, `print(e"")` prints two backslashes, >> and `print(e"\\\")` seems to try to escap

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

On 5/2/16 09:53, Brent Royal-Gordon via swift-evolution wrote: > When you are embedding enormous string literals in source code, you > must put undistorted representation of the string above all other > considerations. If the design which best permits the string to be > w

Re: [swift-evolution] [Idea] Remove optional pattern binding

Ah, I’m just thinking about it in terms of too narrow a case, that makes sense! Put me down as a +1 for the change and solution then. > On 2 May 2016, at 11:56, Антон Жилин wrote: > > Currently, > > if case let x? = y { ... } > > is a sugared version of: > > if case let .some(x) = y { ... }

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

It’s not the keys that are the problem; it’s the values. String and Array are not AnyObjects. Today they get an implicit conversion because they are known-bridgeable. Jordan > On Apr 30, 2016, at 12:44, Jean-Daniel Dupas wrote: > > Is this is a plist like construct, couldn’t it simply be decl

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

> On May 1, 2016, at 7:40 PM, Dave Abrahams via swift-evolution > wrote: > > The specific meaning of sizeof in Swift comes from either LLVM or from > SIL, IIRC. It predates me, but it's supposed to correspond to what the > IRGen level of the compiler calls “sizeof.” LLVM doesn't call anything

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution > wrote: > >> Pattern binding for optionals will look like: >> >> if let x? = y { ... } > > I suggested precisely this in February. The core team shot it down: > >> We tried this* and got a lot of negative feedback. Optionals

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Sun May 01 2016, Xiaodi Wu wrote: > It's a bad habit of mine, I guess, to err on the side of suggesting > conservative > changes on the assumption that it'll be maximally acceptable. If there's > appetite for a more serious renaming, and as you say these are considered > relatively rarely us

[swift-evolution] [Proposal] Improving operator requirements in protocols

I've written a proposal to formalize some of the discussion that was had over in the thread for the `FloatingPoint` protocol proposal regarding improvements to operator requirements in protocols that do not require named methods be added to the protocol and conforming types. Thanks to everyone who

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I like it, but how do you accommodate sizeofValue, etc? On Mon, May 2, 2016 at 11:46 Dave Abrahams wrote: > > on Sun May 01 2016, Xiaodi Wu wrote: > > > It's a bad habit of mine, I guess, to err on the side of suggesting > conservative > > changes on the assumption that it'll be maximally accept

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

> On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution > wrote: > > > on Sun May 01 2016, Xiaodi Wu wrote: > >> It's a bad habit of mine, I guess, to err on the side of suggesting >> conservative >> changes on the assumption that it'll be maximally acceptable. If there's >> appetit

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution > wrote: > I was just thinking that: > protocol Foo : reference {} > might be more to the point than: > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* > reference-semantics type of

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > wrote: >> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Pattern binding for optionals will look like: >>> >>> if let x? = y { ... } >> >> I suggested precisely this in February. The core team

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

Hi swift-evo, Forgive my naive interjection here. I’ve enjoyed lurking on this list and watching all the discussions around topics I don’t even fully understand, but this one strikes me. I certainly agree that multi-line literals should be undistorted, and I also agree that they should be 100

Re: [swift-evolution] [Idea] Remove optional pattern binding

On May 2, 2016, at 11:12 AM, John McCall via swift-evolution wrote: > >> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >> wrote: >>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution >>> wrote: >>> Pattern binding for optionals will look like: if

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

On May 2, 2016, at 13:10, John McCall mailto:rjmcc...@apple.com>> wrote: >> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> I was just thinking that: >> protocol Foo : reference {} >> might be more to the point than: >> protocol Foo :

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

comments below. > Am 28.04.2016 um 20:12 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0052: Change IteratorType post-nil guarantee" begins now > and runs through May 3. The proposal is available here: > > > https://github.com/apple/swif

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 11:47 AM, Chris Lattner wrote: > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > wrote: >> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >>> wrote: On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution wrote: >

[swift-evolution] proposal for a even simpler guard.. => guard!

Hello, often the guard statement is used to only unwrap optionals. multiple guards will cause a lot of ‘overhead’. also often if it doesn’t work. there is no easy way we can gracefully recover ;) so how about we do the same as with try/catch where you can use try! and have a guard! the guard! c

Re: [swift-evolution] [Idea] Remove optional pattern binding

Question coming of a pure curiosity, although somewhat related: isn’t the fact that the Optional is an enum just an implementation detail? I thought this was the case. >From this perspective `if let value = optional` is and will stay an >optional-only syntax regardless of the implementation. `i

Re: [swift-evolution] [Idea] Remove optional pattern binding

I absolutely agree with John, and I think, we should push this through evolution process. That old voting wasn't public, or "official". I insist that we decide this via a formal review. Even if it means that the proposal will be explicitly rejected. - Anton 2016-05-02 22:07 GMT+03:00 John McCall

Re: [swift-evolution] Auto Unwrapping Of Optionals

"I wonder if we’re pushing down the road of convenience at the expense of truth. The if/guard let syntax is clear that you’re getting a separate reference or copy, but what you’re suggesting is hiding the reality from the user for what I see as relatively little convenience." It just might be m

Re: [swift-evolution] Protocol non-conformance clause

> Am 01.05.2016 um 23:34 schrieb Xiaodi Wu : > > The point is pretty much moot. In Erica's draft proposal, keywords are > required in any Swift code that hasn't been compiled in order to indicate > conformance. Under that scheme, it might be useful to be able to express > something like what E

Re: [swift-evolution] [Idea] Remove optional pattern binding

I totally agree with you. I think there are many things that are really well-designed in Swift 2 currently, and most things should stay the way they are. I felt that it is really easy to learn (compared to other languages like, e.g. Perl or Haskell at least) and that the code usually works as ex

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

By existing semantics of the exclamation mark, ‘guard!' would be expected to cause the application to fail fatally, not throw. This is the same as try!. -DW > On May 2, 2016, at 1:09 PM, Dominik Pich via swift-evolution > wrote: > > Hello, > often the guard statement is used to only unwrap op

Re: [swift-evolution] [Idea] Remove optional pattern binding

> The reason is simple: most developers don’t grok pattern matching. > Particularly for people new to swift, “if let” is taught as a magic for > dealing with optionals (which it is). This is a very useful mechanic when > working in Swift, and this way of thinking is fine. Optionals are very >

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Mon May 02 2016, Joe Groff wrote: >> On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Sun May 01 2016, Xiaodi Wu wrote: >> > >>> It's a bad habit of mine, I guess, to err on the side of suggesting >>> conservative >>> changes on the assumption that it

[swift-evolution] [Pitch] Permit self in type-inferred property initializers

I propose that it should be possible to declare type-inferred properties that derive from the required properties of a class or struct. struct SignedSequences { let seq: S let absoluteEvens: self.seq.lazy.filter({ x in x % 2 == 0 }).map({ x in abs(x) }) let positiveOdds: self.seq.la

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Mon May 02 2016, Xiaodi Wu wrote: > I like it, but how do you accommodate sizeofValue, etc? IMO you don't. I added those years ago on a whim, when whims were what we had to guide development. I'm unconvinced they add value to Swift. > > > On Mon, May 2, 2016 at 11:46 Dave Abrahams > wrot

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

yes. true. that’d be also totally fine. my main issue is to make unwrapping easier ;) > On May 2, 2016, at 9:57 PM, David Waite wrote: > > By existing semantics of the exclamation mark, ‘guard!' would be expected to > cause the application to fail fatally, not throw. This is the same as try!.

Re: [swift-evolution] Auto Unwrapping Of Optionals

It is a bad idea to have the compiler change the interpretation of a type without some hard and fast rules; the compiler’s interpretation of the optionality of your code will result in your code being legal or not. In terms of solutions, I would prefer something similar to a guard statement tha

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 12:13 PM, Антон Жилин wrote: > I absolutely agree with John, and I think, we should push this through > evolution process. > > That old voting wasn't public, or "official". > I insist that we decide this via a formal review. Even if it means that the > proposal will be expl

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Tony, thanks for writing this up! on Mon May 02 2016, Tony Allevato wrote: > Other kinds of operators (prefix, postfix, assignment) > > Static operator methods have the same signatures as their global counterparts. > So, for example, prefix and postfix operators as well as assignment operators

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I agree that the names could be more specific but I do agree that putting these methods on `Any` is a good idea. (I am not saying that `Any` should be open to user extensions though.) > On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 02 2016, Joe Grof

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > Open issue: Class types and inheritance > > While this approach works well for value types, these static operators may not > work as expected for class types when inheritance is involved, and more work > may > be needed here. > > We can currently model

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > Acknowledgments > > Thanks to Chris Lattner and Dave Abrahams for contributing to the early > discussions, particularly regarding the need to improve type checker > performance > by genericizing protocol-based operators. FWIW, I think you have omitted

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Tony, thanks for writing this up! > > on Mon May 02 2016, Tony Allevato wrote: > > > Other kinds of operators (prefix, postfix, assignment) > > > > Static operator methods have the same signat

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

> On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 02 2016, Joe Groff wrote: > >>> On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Sun May 01 2016, Xiaodi Wu wrote: >>> >> It's a bad habit of mine, I g

Re: [swift-evolution] Auto Unwrapping Of Optionals

Yeah, I definitely see your concerns about such code. That said, unless the compiler does a lot of rearranging under the covers, all you're asking he compiler to do is to hide the ! for you, which is something you should be aware of. If the compiler does the rearrangement, you're asking for two

[swift-evolution] [Idea] Make lazy an attribute

One of proposals that will probably be submitted for Swift 4, will be Property Behaviors propoal. It aims to generalize @IBOutlet, @synchronized, @delayedinit, and of course, @lazy. (Side note: it would be great if it also included unowned) Because we aim for less breaking changes in Swift 4, we

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:25 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > Open issue: Class types and inheritance > > > > While this approach works well for value types, these static operators > may not > > work as expe

Re: [swift-evolution] Auto Unwrapping Of Optionals

Wow, I'm really sad I missed this while I was writing my last response! I completely agree with this, and that is a much better solution than the ones previously suggested. - Rod > On 3 May 2016, at 6:16 AM, David Waite wrote: > > It is a bad idea to have the compiler change the interpretati

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:30 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > Acknowledgments > > > > Thanks to Chris Lattner and Dave Abrahams for contributing to the early > > discussions, particularly regarding the need

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

Well, I mean, it's not as though you invented them just for Swift. It's possible to evaluate sizeof an instance in C, C++, C#, D, Python, Rust... Removing this facility from Swift is a whole nother discussion from renaming. On Mon, May 2, 2016 at 3:11 PM, Dave Abrahams via swift-evolution < swift

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Tony Allevato wrote: > On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution > wrote: > > Tony, thanks for writing this up! > > on Mon May 02 2016, Tony Allevato wrote: > > > Other kinds of operators (prefix, postfix, assignment) > > > > Stati

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

on Mon May 02 2016, Joe Groff wrote: >> On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon May 02 2016, Joe Groff wrote: >> > On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution wrote: on Sun May 01 2016, Xiaodi Wu

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Maybe one minimalist approach could be to have these take two arguments as though it's an infix operator where one of lhs or rhs is Void: T.++(&value, ()) //postfix T.++((), &value) // prefix On Mon, May 2, 2016 at 15:56 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on

Re: [swift-evolution] Auto Unwrapping Of Optionals

+1 on the shadow variable idea. What an awesome idea. - Tod On 5/2/16, 4:41 PM, "Rod Brown" wrote: >Wow, I'm really sad I missed this while I was writing my last response! > >I completely agree with this, and that is a much better solution than the ones >previously suggested. > >- Rod > >

Re: [swift-evolution] Auto Unwrapping Of Optionals

yes - that is a wonderful syntax addition in my opinion. Josh > On May 2, 2016, at 2:08 PM, Tod Cunningham via swift-evolution > wrote: > > +1 on the shadow variable idea. What an awesome idea. > > - Tod > > > > > > On 5/2/16, 4:41 PM, "Rod Brown" wrote: > >> Wow, I'm really sad I miss

Re: [swift-evolution] [Idea] Remove optional pattern binding

John, When the core team implemented the `if let x? = y` experiment and later backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as nice as it sounds, it didn’t work out in practice.” sounds very definite, as if it was an obvious and unanimous decision to backtrack. I t

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:56 PM Dave Abrahams wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution > > wrote: > > > > How does one distinguish between calls to a static prefix operator > and a > > static postfix operat

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 2:01 PM Xiaodi Wu wrote: > Maybe one minimalist approach could be to have these take two arguments as > though it's an infix operator where one of lhs or rhs is Void: > > T.++(&value, ()) //postfix > T.++((), &value) // prefix This feels a little too much like the "magic

Re: [swift-evolution] [Idea] Make lazy an attribute

Yeah, I was just thinking that we should get the “call-site” syntax settled for property behaviors, for exactly that reason. > On May 2, 2016, at 3:39 PM, Антон Жилин via swift-evolution > wrote: > > One of proposals that will probably be submitted for Swift 4, will be > Property Behaviors pr

Re: [swift-evolution] throw expressions in ternary operators

> On May 2, 2016, at 6:41 AM, Krzysztof Siejkowski via swift-evolution > wrote: > >> Correct, it is not ternary, just a slip of my mind :) > > I have a great amount of understanding for that, I find `nil coalescing > operator` name simply impossible to remember :) > > > >> I didn’t know th

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution wrote: >>> >>> I'd rather have >>> >>> MemoryLayout.size >>> MemoryLayout.alignment >>> MemoryLayout.spacing >> >> This would be a legit use for 'extension Any'. IMO it'd be even better >> as just T.size, T.alignment, T.spacing. >

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 1:19 PM, John McCall wrote: > >> On May 2, 2016, at 12:13 PM, Антон Жилин > > wrote: >> I absolutely agree with John, and I think, we should push this through >> evolution process. >> >> That old voting wasn't public, or "official". >> I insi

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:35 PM, Chris Lattner wrote: >> On May 2, 2016, at 1:19 PM, John McCall > > wrote: >> >>> On May 2, 2016, at 12:13 PM, Антон Жилин >> > wrote: >>> I absolutely agree with John, and I think, we should push this through

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution wrote: > I’d like to propose the following changes: > > Dynamic casts as?, as! and is should no longer perform bridging conversions > between value types and Cocoa classes. > Coercion syntax as should no longer be used to explicitly for

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution > wrote: >> NSError bridging can also be extracted from the runtime, and the same >> functionality exposed as a factory initializer on NSError: >> > > I think that this proposal is overall really great, but what does it do to >

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:17 PM, David Hart wrote: > John, > > When the core team implemented the `if let x? = y` experiment and later > backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as > nice as it sounds, it didn’t work out in practice.” sounds very definite, as > i

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

> Hello Swift community, > > The review of "A New Model for Collections and Indices" begins now and runs > through April 18th. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 2:48 PM, Erica Sadun wrote: > > >> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> NSError bridging can also be extracted from the runtime, and the same >>> functionality exposed as a factory initializer on NS

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 4:15 PM, Chris Lattner wrote: > >> >> On May 2, 2016, at 2:48 PM, Erica Sadun > > wrote: >> >> >>> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: NSError bridging can also be e

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

I got the reference, made me laugh :) > On 03 May 2016, at 00:21, Erica Sadun via swift-evolution > wrote: > > >> On May 2, 2016, at 4:15 PM, Chris Lattner > > wrote: >> >>> >>> On May 2, 2016, at 2:48 PM, Erica Sadun >> > wrote: >>> >

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 3:21 PM, Erica Sadun wrote: > > >> On May 2, 2016, at 4:15 PM, Chris Lattner > > wrote: >> >>> >>> On May 2, 2016, at 2:48 PM, Erica Sadun >> > wrote: >>> >>> On May 2, 2016, at 3:45 PM, Chris Lattner via swif

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 2:45 PM, Chris Lattner wrote: > > On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution > wrote: >> I’d like to propose the following changes: >> >> • Dynamic casts as?, as! and is should no longer perform bridging >> conversions between value types and Cocoa c

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I’ve updated the proposal with comments from the discussions and opened a pull request. Please let me know if you have any feedback before it’s merged: More Powerful Constraints for Associated Types Proposal: SE-

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Hello Tony, Sorry, I never took the time to comment. I see the issues you are pointing, but they seem to be more generic than only concerning associated type constraints. For example, the "inheritance from non-protocol, non-class type” error also concerns generic types. Perhaps it should be bes

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Hi Doug, In the latest version of the proposal, which is now linked to a pull request, I mentioned in the Detail Design section that the following syntax be valid: protocol R : Q where AssocType : P { // … } Can you read through that part of the proposal and let me know if it is descriptive

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 3:43 PM, Joe Groff wrote: > > >> On May 2, 2016, at 2:45 PM, Chris Lattner wrote: >> >> On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution >> wrote: >>> I’d like to propose the following changes: >>> >>> • Dynamic casts as?, as! and is should no longer perf

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 3:50 PM, Chris Lattner wrote: > > >> On May 2, 2016, at 3:43 PM, Joe Groff wrote: >> >> >>> On May 2, 2016, at 2:45 PM, Chris Lattner wrote: >>> >>> On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution >>> wrote: I’d like to propose the following changes:

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution wrote: >>How does one distinguish between calls to a static prefix operator and a >>static postfix operator with the same name? >> >> Ah, that's a tricky one that I don't have an immediate answer to, so I'm >> definitely open

Re: [swift-evolution] [Manifesto] Completing Generics

I’d like to continue moving Completing Generics forward for Swift 3 with proposals. Can Douglas, or someone from the core team, tell me if the topics mentioned in Removing unnecessary restrictions require proposals or if bug reports should be opened for them instead? > On 03 Mar 2016, at 02:22,

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 4:24 PM, Tony Allevato wrote: > On Mon, May 2, 2016 at 2:01 PM Xiaodi Wu wrote: > >> Maybe one minimalist approach could be to have these take two arguments >> as though it's an infix operator where one of lhs or rhs is Void: >> >> T.++(&value, ()) //postfix >> T.++((), &v

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

> On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution > wrote: > > On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution > wrote: >>> How does one distinguish between calls to a static prefix operator and a >>> static postfix operator with the same name? >>> >>> Ah, tha

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

I like the direction this takes things! Thanks for hammering out a proposal to get the ball rolling. -Shawn On Mon, May 2, 2016 at 9:51 AM Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > I've written a proposal to formalize some of the discussion that was had > over in th

Re: [swift-evolution] Auto Unwrapping Of Optionals

The difference between the if-let syntax and the below syntax is that the type of foo never changes with the if-let syntax. Instead a new variable is created which shadows the original foo. The distinction is important because types don’t implicitly change in Swift. The implicit change is called

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

We have that; it’s just ‘!’. :-) Jordan > On May 2, 2016, at 12:09, Dominik Pich via swift-evolution > wrote: > > Hello, > often the guard statement is used to only unwrap optionals. multiple guards > will cause a lot of ‘overhead’. > also often if it doesn’t work. there is no easy way we can

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 5:53 PM, Joe Groff via swift-evolution > wrote: > > I can't think of any problems that would block us from doing that today. It'd > be pretty easy to write an ErrorProtocol extension that just forwards > NSError's interface via bridging, and I bet that'd cover most use cas

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

On Mon, May 2, 2016 at 4:32 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >>> > >>> I'd rather have > >>> > >>> MemoryLayout.size > >>> MemoryLayout.alignment > >>> M

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Hmm, a thought going in a slightly different direction: if these static functions were called like any other function, there might not be a need for having special rules for parameter labels, which can then be freed to denote prefix and postfix operators. In other words, we could have: * for infix

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

> On May 2, 2016, at 9:44 AM, Tony Allevato via swift-evolution > wrote: > > I've written a proposal to formalize some of the discussion that was had over > in the thread for the `FloatingPoint` protocol proposal regarding > improvements to operator requirements in protocols that do not requi

  1   2   >