Re: [swift-evolution] "with" operator a la O'Caml?

But for a struct to be immutable, you don't need all its properties to be let. (I guess that's Derrick's point) ´´´ struct Person { /* . . . var properties . . . */ } let john = Person() // john is completely immutable ´´´ If a struct has var properties, you can do a mutable copy, change it, ass

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

Choice for choice's sake as in 100s of ways to do the same thing leads to confusion and complexity. My suggestions are to make Swift consistent, simple, and clear. As it is right now, the motives to keep things status quo in Swift are the same reasons MS Windows was more difficult to use than th

Re: [swift-evolution] URL Literals

Regex is another thing that appears on many platforms and has a standard way to express it. -- E > On Dec 19, 2016, at 5:51 PM, Jonathan Hull wrote: > > +1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in > Xcode where possible) > > Perhaps the easiest way to allow arb

Re: [swift-evolution] URL Literals

Mixfix operators were a possibility sketched out in a recent proposal draft on operators by Jonathan Shapiro. That would enable custom syntax like you show here. Not sure if a revision of that draft is still in the works. On Mon, Dec 19, 2016 at 22:37 Daniel Leping via swift-evolution < swift-evo

Re: [swift-evolution] URL Literals

I believe regex was one of the topics that the core team proposed was a possibility for phase 2. I too am eager to hear what they have in mind. On Mon, Dec 19, 2016 at 23:02 Erica Sadun wrote: > Regex is another thing that appears on many platforms and has a standard > way to express it. > > -- E

Re: [swift-evolution] URL Literals

I was thinking about a possibility to extend the language itself with custom literals. It should cover quite some stuff including URL, Regex, etc. Just add an extended operator-ish syntax. Can be done with regular expressions or similar. //RegexLiteralDefinition literal /(.*)/(.*)/ (regex:String,

Re: [swift-evolution] URL Literals

+1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in Xcode where possible) Perhaps the easiest way to allow arbitrary literal extensions beyond those would be, in phase 2 when we add RegEx to the language, to take a RegEx defining the custom literal and have the compiler o

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

2016-12-20 0:59 GMT+03:00 Derrick Ho : The core team designed swift blocks to range from concise to verbose. Which > one you use depends on your needs. > > If you want to write parenthesis then by all means write parenthesis; no > one is stopping you. > > I would rather keep the block syntax as it

Re: [swift-evolution] "with" operator a la O'Caml?

More advanced mirroring is one of those things that is on the agenda somewhere. It would stand to reason that a generalizable solution which doesn't need to be created for each struct would become possible when that arrives, no? On Mon, Dec 19, 2016 at 16:08 Andy Chou via swift-evolution < swift-e

Re: [swift-evolution] "with" operator a la O'Caml?

Value semantics help reduce the issues around mutability, but they don't go away completely. I would like to create structs that are completely immutable after construction. Turning the properties into vars unfortunately loses this idea. The proposed 'with' function doesn't construct new instan

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

The core team designed swift blocks to range from concise to verbose. Which one you use depends on your needs. If you want to write parenthesis then by all means write parenthesis; no one is stopping you. I would rather keep the block syntax as it is so that everyone can choose the style that mat

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On Dec 19, 2016, at 1:57 PM, Kevin Ballard wrote: > > On Fri, Dec 16, 2016, at 06:30 AM, Charles Srstka wrote: >>> On Dec 16, 2016, at 12:36 AM, Kevin Ballard >> > wrote: >>> >>> On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: > On Dec 15, 2016, at 4:33 PM, Ke

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

This issue about `numbers in` was raised during review of SE-0066; if I recall, the core team considered and rejected disallowing that syntax in closures. Since we're minimizing source-breaking changes, the issue is settled in my view, having been proposed, commented upon, reviewed, and rejected. O

Re: [swift-evolution] "with" operator a la O'Caml?

That is correct Andy. Let-constant can not be assigned a new value after it gets its initial value. It is unclear why you are against turning your properties into var's. Because you are using structs, all properties are copied by value. struct Person { var name: String } let andy = Person(name

Re: [swift-evolution] "with" operator a la O'Caml?

+1 on this. Scala also has a similar feature (copy constructor) for its case classes. Right now there's no generic way to do this in Swift, besides resorting to code generation. Would this feature have an impact on the ABI and therefore be considered for Swift 4 part 1? -Miguel On Mon, Dec 19, 2

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution < swift-evolution@swift.org>: var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = { > numbers -> ([Int], [Int]) in > var evenNumberArray = [Int]() > var oddNumberArray = [Int]() > > for number in numbers { >

Re: [swift-evolution] "with" operator a la O'Caml?

Thanks Erica, I wasn't aware of that proposal. If I'm reading it right, the proposed 'with' function won't work for let-constants in structures, e.g.: struct Person { let name: String let address: String } @discardableResult public func with(_ item: T, update: (inout T) throws -> Void) r

Re: [swift-evolution] "with" operator a la O'Caml?

Thanks Erica, I wasn't aware of that Swift evolution proposal. If I'm reading it right, this wouldn't work with structs with let-variables...? Here's what I get with this example: struct Person { let name: String let address: String } @discardableResult public func with(_ item: T, upda

Re: [swift-evolution] Pattern matching with Arrays

2016-12-19 3:09 GMT+03:00 Lucas Neiva via swift-evolution < swift-evolution@swift.org>: > case let [first, next...]: > > case let [first, last]: > > The binding should be more like "[let first, let last]" though, to be more > like the tuple matching. For the above also: "case [let head, let tail..

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

For me, it wouldn't be important to access those classes from ObjC — but I would appreciate being able to use classes with generic ancestors in Xibs. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swif

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:55 AM, David Sweeris via swift-evolution > wrote: > > >> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu > > wrote: >> >> On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On De

Re: [swift-evolution] URL Literals

The behavior is not altogether clear to me either. Since XCode does show a preview of images, it's fair to think that there's some sort of compile-time validation going on. I would not be opposed to image and file literals changing their behavior so that when a user drags a file into the IDE the f

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Fri, Dec 16, 2016, at 06:30 AM, Charles Srstka wrote: >> On Dec 16, 2016, at 12:36 AM, Kevin Ballard wrote: >> >> On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: On Dec 15, 2016, at 4:33 PM, Kevin Ballard wrote: The problem with that code isn't that `dynamic` doesn'

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu wrote: > > On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution < > swift-evolution@s

Re: [swift-evolution] "with" operator a la O'Caml?

https://github.com/apple/swift-evolution/pull/346 Be aware that there's a bug that's being worked on: https://bugs.swift.org/browse/SR-2773 -- E > On Dec 19, 2016, at 12:40 PM, Andy Chou via swift-evolution > wrote: > > Of course. Thanks

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution > wrote: > > >> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> ```swift >> let x = #imageLiteral(resourceName:"nothere.jpg") >> print(x) >> ``` >> >> This comp

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:40 PM, Xiaodi Wu wrote: > On Mon, Dec 19, 2016 at 1:18 PM, Tony Allevato > wrote: > >> +1 to the sentiment in your last paragraph. >> >> In general, I'm not a very big fan of the #foo(...) syntax for literals >> and I think using that as the starting point for discussio

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:18 PM, Tony Allevato wrote: > +1 to the sentiment in your last paragraph. > > In general, I'm not a very big fan of the #foo(...) syntax for literals > and I think using that as the starting point for discussion biases us > towards those when more general and powerful al

Re: [swift-evolution] "with" operator a la O'Caml?

Of course. Thanks for pointing out the obvious solution. This preserves the immutability of the struct and doesn't require O(n^2) code for structs with large numbers of fields. I was thinking of a generic solution - perhaps something like a synthetic initializer that does what your solution do

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution > wrote: > > ```swift > let x = #imageLiteral(resourceName:"nothere.jpg") > print(x) > ``` > > This compiles. It crashes at runtime. I don't see why URLs should be any > different. > > — E They shouldn’t be. The print function

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 12:18 PM, Tony Allevato via swift-evolution > wrote: > > +1 to the sentiment in your last paragraph. > > In general, I'm not a very big fan of the #foo(...) syntax for literals and I > think using that as the starting point for discussion biases us towards those > when

Re: [swift-evolution] "with" operator a la O'Caml?

A little more work, but I like this pattern. struct Person { let name: String let address: String let phone: String func name(_ n: String) -> Person { return Person(name: n, address: self.address, phone: self.phone) } func address(_ a: String) -> Pers

Re: [swift-evolution] URL Literals

```swift let x = #imageLiteral(resourceName:"nothere.jpg") print(x) ``` This compiles. It crashes at runtime. I don't see why URLs should be any different. -- E > On Dec 19, 2016, at 11:53 AM, David Sweeris via swift-evolution > wrote: > >> >> On Dec 19, 2016, at 1:26 AM, Xiaodi Wu >

Re: [swift-evolution] URL Literals

+1 to the sentiment in your last paragraph. In general, I'm not a very big fan of the #foo(...) syntax for literals and I think using that as the starting point for discussion biases us towards those when more general and powerful alternatives could exist. That syntax exists for Playground support

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 1:26 AM, Xiaodi Wu wrote: > > URLs are unlikely to be something that can be validated by regex. See, for > instance, this discussion: > >. The full spec is > here

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 8:47 AM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: > Regarding validation of resources being reachable or existing, I think we > should take that right off the table, for all types of URLs. Firstly, > because it could be very error prone. Consid

Re: [swift-evolution] "with" operator a la O'Caml?

struct Person { Var name: String = "" func with(name n: String) -> Person { var a = self a.name = name return a } } let andy = Person().with(name: "Andy") let brandon = andy.with(name: "Brandon") On Mon, Dec 19, 2016 at 10:28 AM Andy Chou via swift-evolution < swift-evolution@swift.org> wrote: >

[swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

When using Closures in Swift, you declare the parameter names inside the curly brackets. How come for tuples you don't, but declare them outside? Also, why do single parameters not need parentheses? This makes Swift inconsistent, e.g. var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd

[swift-evolution] "with" operator a la O'Caml?

I like that structs are value types in Swift, this encourages the use of immutable data. O'Caml has an operator "with" that allows for copying an existing struct with a change to one field. I looked at Lenses for this functionality and it seems like a lot to digest for something so simple. I als

[swift-evolution] URL Literals

I would like to be able to create a URL literal that is compile-time checked for correct format. This would help avoid code like this: let url = URL(string: "https://example.com";)! The cleanest way I can think of doing that would be to introduce a new macro structure similar to #selector, th

Re: [swift-evolution] Add ability to validate collection indices

> On 19 Dec 2016, at 04:10, Dave Abrahams via swift-evolution > wrote: > > > on Fri Dec 16 2016, Daniel Vollmer > wrote: > >> Hi, >> >>> On 16 Dec 2016, at 14:56, Alexey Komnin via swift-evolution >>> wrote: >> >> [snip] >> >>> What do you think? I feel

Re: [swift-evolution] URL Literals

Regarding validation of resources being reachable or existing, I think we should take that right off the table, for all types of URLs. Firstly, because it could be very error prone. Consider even the basic case of the deployment environment having access to the resource while the build environment

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:55 AM, Benjamin Spratling wrote: > Howdy, > I'm definitely on the "no force unwrapping bandwagon". And I also see > a huge difference in force-unwrapping a value derived from a literal, which > can be unit tested, and force-unwrapping a value determined at run time,

Re: [swift-evolution] URL Literals

URLs are unlikely to be something that can be validated by regex. See, for instance, this discussion: < https://webkit.org/blog/7086/url-parsing-in-webkit/>. The full spec is here: . If Swift were to implement parsing of URLs at the level of the compiler or core library

Re: [swift-evolution] URL Literals

Howdy, Yes, I was also intrigued by the “Regex” validation mentioned in another post. It could offer a convenient way to get some literals support in without the headaches associated with the constexpr C++ approach. I’m curious, though, how many types can we image in can be valid

Re: [swift-evolution] URL Literals

I like where this is going! +1 Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 19 Dec 2016, at 08:41, David Sweeris via swift-evolution > wrote: > > >> On Dec 17, 2016, at 1:12 PM, Micah