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

[Rod Brown via swift-evolution]

> On 30 Dec 2016, at 10:50 am, Freak Show  wrote:
> 
> 
>> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> I’m in agreement that ‘dynamic’ is probably not what you want without a 
>> declaration.
> 
> I hold a completely opposite viewpoint.  Dynamic is always what I want and 
> table based is premature optimization.  Late binding is important.  I found 
> far too often when working in C++ (yes I am really flipping old) I would come 
> across code where a developer hadn't chosen to make a method virtual and I 
> found myself just up a creek with regards to extending that code.  Ditto 
> people declaring stuff final in Java for no good reason.
> 
> The important thing to consider is that the future is generally unknowable 
> and if you don't know the future you cannot make good choices about what 
> should and should not be dynamic.  So the conservative thing is to make 
> everything dynamic until you cannot afford it - which...is usually never.

Then that’s great. If you’d prefer to work with a more open, overridable and 
intercetable platform which is dynamic by default, Apple has your back: Obj-C. 
It’s not deprecated. It’s actually the language they’re still writing iOS, OS 
X, tvOS and watchOS higher level frameworks in still, so you’re covered. Who is 
forcing you to use Swift, a language where compiler optimisations like this a 
stated goal?

> 
>> The only difference between table and method dispatch is the Objective-C 
>> message dispatch system. Unless users want to work around things by manually 
>> handling with some of the complex machinery in Obj-C, which is rare, then 
>> there is no reason behind doing so, and all it comes down to is a relatively 
>> large performance hit for nothing. And to be honest, with very few 
>> exceptions, if you’re using that ultra-dynamic machinery, you’re probably 
>> Doing It Wrong in the first place.
> 
> I do this sort of thing routinely and I assure you I am not Doing It Wrong.

Ok, so you do it a lot. That means definitively it’s the best way?

Obj-C was designed to constantly be interfering with method dispatch? You can 
do it, it’s there, message forwarding, those types of mechanisms, but if you’re 
relying on that for your day-to-day work, you’re in for a load of trouble, and 
you’re hacking around frameworks using the language rather than working with 
the frameworks. Apple don’t design their frameworks first and foremost for us 
to get in there and start using method swizzling or the like - in fact they 
specifically discourage it. Just because you do it and you think you’re smart 
doesn’t make it good design.

There are rare instances where frameworks and implementations use some of the 
really dynamic stuff, like CoreData, or KVO. That’s great. I’m not arguing 
there isn’t a use for it. I’m saying you pay a massive hit, 90% of the time for 
no reason.

> 
> I don't get why there is so much emphasis on performance in this day and age. 
>  I haven't run into a performance problem I could trace to speed of 
> ObjectiveC's method dispatching since the early 90’s.

Do a time profile of a modern Obj-C application. You’ll find that 15% of the 
time the application is running, it’s stuck in the middle of objc_msgSend. 
That’s a massive overhead in anyone’s books. Why is this important?

1. More CPU use equals more battery drain. Considering the vast majority of 
Apple’s platforms and the direction of computing as a whole is dependent on 
batteries rather than plugs in walls, this is important.

2. Moore’s Law won’t continue. We’re getting to the end of the road in what CPU 
advances have given us, and all those core multiplications just ends in more 
locks - we need to be more efficient because in 40 years of computing, we 
haven’t worried about making our software better, we just waited for CPU’s to 
catch up. News Flash: They won’t. Time for us to stop justifying ourselves and 
do something about making ourselves better at using the processing power we 
have.

3. Swift wasn’t designed just to replace Obj-C, a relatively high level 
language. It was designed to scale from system programming to the higher levels 
as well. Obj-C is good for basic UI development because you rarely tax the 
limits and are rarely worried about getting performance out of it.

4. Because performance in the language and its frameworks benefits everyone by 
giving more flexibility to their users.

> 
> Second - I have quite a lot of code that relies on this sort of dynamism. 
> I've been a very serious C++ developer and a very serious Smalltalk 
> programmer at various times in my career and I value the flexibility of late 
> binding far above performance.
> 
>> If you need this functionality, dynamic still exists. But Swift is Table 
>> Dispatch by default for a reason: you’re paying a massive penalty for 
>> something you’ll rarely if ever use, and it should be opt in.
> 
> Strongly disagree.  
>> 
>> 
>>> 

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

[Dave Abrahams via swift-evolution]

on Thu Dec 29 2016, Freak Show  wrote:

>> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> I’m in agreement that ‘dynamic’ is probably not what you want without a 
>> declaration.
>
> I hold a completely opposite viewpoint.  Dynamic is always what I want
> and table based is premature optimization.  Late binding is important.
> I found far too often when working in C++ (yes I am really flipping
> old) I would come across code where a developer hadn't chosen to make
> a method virtual and I found myself just up a creek with regards to
> extending that code.  Ditto people declaring stuff final in Java for
> no good reason.
>
> The important thing to consider is that the future is generally
> unknowable and if you don't know the future you cannot make good
> choices about what should and should not be dynamic.  So the
> conservative thing is to make everything dynamic until you cannot
> afford it - which...is usually never.

By that measure there should be no encapsulation; we should make
everything public, because somebody might need it someday.

Cheers,

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Freak Show via swift-evolution]

> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution 
>  wrote:
> 
> I’m in agreement that ‘dynamic’ is probably not what you want without a 
> declaration.

I hold a completely opposite viewpoint.  Dynamic is always what I want and 
table based is premature optimization.  Late binding is important.  I found far 
too often when working in C++ (yes I am really flipping old) I would come 
across code where a developer hadn't chosen to make a method virtual and I 
found myself just up a creek with regards to extending that code.  Ditto people 
declaring stuff final in Java for no good reason.

The important thing to consider is that the future is generally unknowable and 
if you don't know the future you cannot make good choices about what should and 
should not be dynamic.  So the conservative thing is to make everything dynamic 
until you cannot afford it - which...is usually never.

> The only difference between table and method dispatch is the Objective-C 
> message dispatch system. Unless users want to work around things by manually 
> handling with some of the complex machinery in Obj-C, which is rare, then 
> there is no reason behind doing so, and all it comes down to is a relatively 
> large performance hit for nothing. And to be honest, with very few 
> exceptions, if you’re using that ultra-dynamic machinery, you’re probably 
> Doing It Wrong in the first place.

I do this sort of thing routinely and I assure you I am not Doing It Wrong.

I don't get why there is so much emphasis on performance in this day and age.  
I haven't run into a performance problem I could trace to speed of ObjectiveC's 
method dispatching since the early 90's.

Second - I have quite a lot of code that relies on this sort of dynamism. I've 
been a very serious C++ developer and a very serious Smalltalk programmer at 
various times in my career and I value the flexibility of late binding far 
above performance.

> If you need this functionality, dynamic still exists. But Swift is Table 
> Dispatch by default for a reason: you’re paying a massive penalty for 
> something you’ll rarely if ever use, and it should be opt in.

Strongly disagree.  
> 
> 
>> On 15 Dec 2016, at 10:15 am, Brian King via swift-evolution 
>>  wrote:
>> 
>> I wanted to follow up to a blog post I wrote about Message Dispatch in
>> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I
>> mentioned some changes to NSObject that didn’t result in any
>> objections, so I thought it was time to see what the SE mailing list
>> thought.
>> 
>> I’ve read a few conversations on SE mailing list that have morphed
>> into abstract conversations about dynamic vs static dispatch. I want
>> to focus specifically on how Swift NSObject subclasses behave.
>> 
>> I think that there are 2 changes that will result in fewer bugs and
>> will not have a substantial impact on performance:
>> 
>> 
>> ## Remove Table Dispatch from NSObject
>> 
>> NSObject subclasses use table dispatch for the initial class
>> declaration block. I think that using message dispatch for NSObject
>> subclasses everywhere will result in a much more consistent developer
>> experience.
>> 
>> ## Block NSObject Visibility Optimizations
>> 
>> Swift upgrades method dispatch to final when the compiler can prove
>> that the method is not subclassed. I would like to see Swift be more
>> careful about the impact of these optimizations on message dispatch,
>> and consider message dispatch non-upgradable.
>> 
>> 
>> I thought it would help to frame this choice as a trade-off between
>> Swift’s goals of safe, fast, and expressive.
>> 
>> ## Safe
>> 
>> Always using message dispatch for NSObject subclasses will fix a class
>> of runtime errors in framework features that are designed around
>> message passing (e.g. KVO). Arguments against using dynamic features
>> like this are valid, but Cocoa frameworks still use dynamic features
>> and the above behaviors result in actual bugs. As a bonus, this will
>> resolve SR-584, where a table-dispatched method that is overridden by
>> a message dispatch method doesn’t behave correctly.
>> 
>> ## Fast
>> 
>> The above changes will result in slower dispatch in NSObject
>> subclasses. However, I don't think that these dispatch changes
>> actually have a tangible impact on performance. Most NSObject
>> subclasses sit on top of a lot of `objc_msgSend`, and if there is a
>> specific hot spot, it would still be optimizable via the final
>> keyword.
>> 
>> ## Expressive
>> 
>> Using table dispatch for NSObject without any source indication or
>> library documentation is not very expressive. I think it’s important
>> to weigh table dispatch behavior against all of the framework
>> documentation and developer experience that assume message dispatch.
>> This will also eliminate the need for a lot of `@objc` and `dynamic`
>> annotations that are often inconsistently applied depending on if they
>> are needed 

Re: [swift-evolution] Replace named returns with `out` parameters?

[Kevin Ballard via swift-evolution]

I know you've already decided against this, but I think it deserves an
explanation for why the two are different.


Tuples in function parameters was basically a special case to the type
system. The function type was effectively modeled as taking one argument
which was a tuple, and a function of multiple arguments just had a multi-
element tuple. But this wasn't actually true. For one thing, you could
have a single named argument, but you cannot have a 1-element tuple
(named or no), which means the function argument isn't _really_ a tuple.
For another, this caused weird behavior when invoking functions with a
single tuple element. I don't remember the specifics anymore (I'm not
sure I ever truly understood the rules around this), but in some cases
you could pass a single tuple to a function expecting multiple
arguments, but in other cases you couldn't.


So ultimately, getting rid of the notion that a function's arguments is
a tuple was actually a simplification to the type system and to the
internals, and made the rules a lot more straightforward.


Now contrast that with the return type. The return type is just a single
value of *any* valid type. And a tuple is a valid type. Therefore, the
return type can be a tuple. That's a straightforward consequence of the
basic rules of the type system. Restricting it so functions couldn't
return a tuple would be a complication to the type system, and a rather
weird one at that. And that's without even considering the complexity
and syntactical issues with your proposed `out` parameter.


-Kevin Ballard



On Wed, Dec 28, 2016, at 03:09 AM, Anton Zhilin via swift-evolution wrote:
> Some people on the list wondered, why we have moved from tuples in
> function parameters, but multiple returns are still implemented using
> tuples? The following code still compiles:


> *func* *position*() -> (x: Int, y: Int) {  *return* (x: , y: ) }

> *let* (y, x) = position()
>
> (Maybe it’s a bad example, because naturally we’d use Point struct.
> Let’s pretend those two parameters don’t make sense as a struct.)
> What I want to discuss is if we should introduce out parameters *and*
> make them the default for multiple returns for Swift 4. The syntax
> would look like:


> *func* *position*(x: out Int, y: out Int) { x =  y =  }

> *var* y position(x: *let* x, y: y)
>
> out arguments can be any patterns allowed on the left side of
> assignment, including wildcard pattern and tuple destructuring
> pattern.
> 

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

I’m in agreement that ‘dynamic’ is probably not what you want without a 
declaration.

There are currently some bugs in how dispatch works for overrides in Swift 
extensions, and I’d like to see any methods that conform to an @objc protocol 
being given an implicit @objc, but true dynamic? No.

The only difference between table and method dispatch is the Objective-C 
message dispatch system. Unless users want to work around things by manually 
handling with some of the complex machinery in Obj-C, which is rare, then there 
is no reason behind doing so, and all it comes down to is a relatively large 
performance hit for nothing. And to be honest, with very few exceptions, if 
you’re using that ultra-dynamic machinery, you’re probably Doing It Wrong in 
the first place. If you need this functionality, dynamic still exists. But 
Swift is Table Dispatch by default for a reason: you’re paying a massive 
penalty for something you’ll rarely if ever use, and it should be opt in.


> On 15 Dec 2016, at 10:15 am, Brian King via swift-evolution 
>  wrote:
> 
> I wanted to follow up to a blog post I wrote about Message Dispatch in
> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I
> mentioned some changes to NSObject that didn’t result in any
> objections, so I thought it was time to see what the SE mailing list
> thought.
> 
> I’ve read a few conversations on SE mailing list that have morphed
> into abstract conversations about dynamic vs static dispatch. I want
> to focus specifically on how Swift NSObject subclasses behave.
> 
> I think that there are 2 changes that will result in fewer bugs and
> will not have a substantial impact on performance:
> 
> 
> ## Remove Table Dispatch from NSObject
> 
> NSObject subclasses use table dispatch for the initial class
> declaration block. I think that using message dispatch for NSObject
> subclasses everywhere will result in a much more consistent developer
> experience.
> 
> ## Block NSObject Visibility Optimizations
> 
> Swift upgrades method dispatch to final when the compiler can prove
> that the method is not subclassed. I would like to see Swift be more
> careful about the impact of these optimizations on message dispatch,
> and consider message dispatch non-upgradable.
> 
> 
> I thought it would help to frame this choice as a trade-off between
> Swift’s goals of safe, fast, and expressive.
> 
> ## Safe
> 
> Always using message dispatch for NSObject subclasses will fix a class
> of runtime errors in framework features that are designed around
> message passing (e.g. KVO). Arguments against using dynamic features
> like this are valid, but Cocoa frameworks still use dynamic features
> and the above behaviors result in actual bugs. As a bonus, this will
> resolve SR-584, where a table-dispatched method that is overridden by
> a message dispatch method doesn’t behave correctly.
> 
> ## Fast
> 
> The above changes will result in slower dispatch in NSObject
> subclasses. However, I don't think that these dispatch changes
> actually have a tangible impact on performance. Most NSObject
> subclasses sit on top of a lot of `objc_msgSend`, and if there is a
> specific hot spot, it would still be optimizable via the final
> keyword.
> 
> ## Expressive
> 
> Using table dispatch for NSObject without any source indication or
> library documentation is not very expressive. I think it’s important
> to weigh table dispatch behavior against all of the framework
> documentation and developer experience that assume message dispatch.
> This will also eliminate the need for a lot of `@objc` and `dynamic`
> annotations that are often inconsistently applied depending on if they
> are needed in the scope they are defined in (e.g. class vs extension).
> 
> 
> If this idea shows promise, I’d be glad to formalize a Swift Evolution
> Proposal and explore syntactic details. I think being able to flag a
> class with `dynamic` and applying this flag to `NSObject` may be the
> only syntactic change needed. However, it would be good to debate the
> merit of the behavior change before the syntax.
> 
> 
> Thanks!
> 
> 
> Brian King
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] URL Literals

[Xiaodi Wu via swift-evolution]

I think for me, the big difference between a color literal and URL literal,
which swayed me in the end was this:

As noted in SE-0039, `[#Color(...)#]` (now `#colorLiteral(...)`) isn't
itself a literal; it's a spelling that allows you to _get_ a literal, which
is a swatch of color. On reflection, whether these things ought to be
termed "literals" exactly like strings is something maybe worth revisiting.
They certainly have benefits (_seeing_ a color is nice), but still,
consider how they differ from string literals, etc:

To me at least, `"foo"` _is_ literally a string and `0` is literally an
integer, both of no particular type until it's assigned to a variable,
which is what literals make possible. By the same token, almost any power
user of computers can recognize that `` _is_ literally
a URL and `/regex/` _is_ literally a regular expression. I'll call these
"true literals" for the moment. There are, naturally, a limited number of
true literals in the world, and that upper bound is not an artificial limit
of any programming language. For that reason, I think we ought not be
concerned about "running out" of delimiters.

Even as I continue to believe that a constexpr-like facility might be the
best holistic solution for those who need compile-time validation of custom
types, I can now see that there are grounds to regard a URL as something
special, a true literal for which there is a rational basis for first-class
support from the compiler.


On Thu, Dec 29, 2016 at 3:49 PM, Xiaodi Wu  wrote:

> On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline 
> wrote:
>
>> I think that's all doable. I'm not sure what delimiters would be the
>> best though, which is why I hadn't moved away from #url yet. I've been
>> thinking hard about the regex, which seems like an even stronger case
>> to make into a literal, and /abc/ works well for those, but even those
>> have some problems, as an empty regex (valid according to
>> NSRegularExpression) of // would parse also as a comment.
>
>
> True, but I doubt that's a common use case. JavaScript supports `/regex/`
> and I haven't heard of complaints re not supporting `//`.
>
>
>> For < and >
>> it could start getting confusing with overloaded operators. I think it
>> would work, but could be a little trickier than it seems like on first
>> blush.
>>
>
> Besides being a natural way of writing it, < and > have the advantage that
> resolving their different uses is already heavily tested (because generics
> use <>, and because the lexer understands merging artifacts like << and
> >>).
>
>
>> It would be easier to lex if it were expressed like
>> #url, but ease of lexing probably doesn't weigh
>> that heavily. If we wanted to do more than string, url, and regex we'd
>> start running out of delimiters fast though...
>>
>
> To me, that's a feature, not a bug. I'd argue that the language should
> provide first-class support for only a few, very important literals (like
> strings). Compile time validation for arbitrary types, as I've said before,
> should probably be solved in other, more holistic ways (such as some sort
> of constexpr-like feature).
>
> Another idea (taking from ruby a little) would be to have something
>> like %url{https://example.com} and %regex{my/regex}
>>
>> In ruby, their %r{} structure can take things other than {} as long as
>> they don't appear in the string (for instance %r@my/regex@ works too),
>> we could do something like that and have a pretty robust structure for
>> whatever literals we wanted going forward, and it should work for url
>> and regex, which are in the more immediate future. Of course, % could
>> just as easily be #.
>
>
> We had that before, essentially. Object literals (file, image, color) were
> spelled like this: [#Color(...)#]. They were removed with SE-0039.
>
>
> On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu  wrote:
>> > Micah,
>> >
>> > I think I'm coming round to your line of thinking re URL literals. It'd
>> be
>> > nice to have them supported first-class, not like image literals (the
>> design
>> > for which is really geared towards playgrounds and is rather hacky,
>> IMO),
>> > but like strings. In that scenario, Foundation URL would conform to
>> > ExpressibleByURLLiteral. URL could even be the default URLLiteralType
>> once
>> > Foundation is imported (just like String is the default
>> StringLiteralType).
>> >
>> > What'd be _really_ nice, though, is to solidify the first-class status
>> of
>> > URL literals by their spelling: not `#urlLiteral(resourceName:
>> "blahblah")`
>> > or even `#url("blahblah")`, but just as you write `let str = "this is a
>> > string"` (and I'm sure we'll have `let regex = /foo/`), we should have
>> `let
>> > url = `. The compiler would ensure that what's
>> between
>> > the delimiters is a valid relative or absolute URL, and
>> `init(urlLiteral:)`
>> > will get a 

Re: [swift-evolution] URL Literals

[Xiaodi Wu via swift-evolution]

On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline 
wrote:

> I think that's all doable. I'm not sure what delimiters would be the
> best though, which is why I hadn't moved away from #url yet. I've been
> thinking hard about the regex, which seems like an even stronger case
> to make into a literal, and /abc/ works well for those, but even those
> have some problems, as an empty regex (valid according to
> NSRegularExpression) of // would parse also as a comment.


True, but I doubt that's a common use case. JavaScript supports `/regex/`
and I haven't heard of complaints re not supporting `//`.


> For < and >
> it could start getting confusing with overloaded operators. I think it
> would work, but could be a little trickier than it seems like on first
> blush.
>

Besides being a natural way of writing it, < and > have the advantage that
resolving their different uses is already heavily tested (because generics
use <>, and because the lexer understands merging artifacts like << and
>>).


> It would be easier to lex if it were expressed like
> #url, but ease of lexing probably doesn't weigh
> that heavily. If we wanted to do more than string, url, and regex we'd
> start running out of delimiters fast though...
>

To me, that's a feature, not a bug. I'd argue that the language should
provide first-class support for only a few, very important literals (like
strings). Compile time validation for arbitrary types, as I've said before,
should probably be solved in other, more holistic ways (such as some sort
of constexpr-like feature).

Another idea (taking from ruby a little) would be to have something
> like %url{https://example.com} and %regex{my/regex}
>
> In ruby, their %r{} structure can take things other than {} as long as
> they don't appear in the string (for instance %r@my/regex@ works too),
> we could do something like that and have a pretty robust structure for
> whatever literals we wanted going forward, and it should work for url
> and regex, which are in the more immediate future. Of course, % could
> just as easily be #.


We had that before, essentially. Object literals (file, image, color) were
spelled like this: [#Color(...)#]. They were removed with SE-0039.


On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu  wrote:
> > Micah,
> >
> > I think I'm coming round to your line of thinking re URL literals. It'd
> be
> > nice to have them supported first-class, not like image literals (the
> design
> > for which is really geared towards playgrounds and is rather hacky, IMO),
> > but like strings. In that scenario, Foundation URL would conform to
> > ExpressibleByURLLiteral. URL could even be the default URLLiteralType
> once
> > Foundation is imported (just like String is the default
> StringLiteralType).
> >
> > What'd be _really_ nice, though, is to solidify the first-class status of
> > URL literals by their spelling: not `#urlLiteral(resourceName:
> "blahblah")`
> > or even `#url("blahblah")`, but just as you write `let str = "this is a
> > string"` (and I'm sure we'll have `let regex = /foo/`), we should have
> `let
> > url = `. The compiler would ensure that what's
> between
> > the delimiters is a valid relative or absolute URL, and
> `init(urlLiteral:)`
> > will get a parsed tuple just as the official standard outlines, with
> scheme,
> > username, password, host, port, cannot-be-a-base-URL flag, path, query,
> > fragment all ready to go. Looking through the lexer, it seems like this
> > _should_ be possible and not inordinate amounts of work. Any thoughts
> about
> > this idea, since you're actively studying the lexer?
> >
> > Xiaodi
> >
> >
> > On Wed, Dec 28, 2016 at 5:18 PM, Xiaodi Wu  wrote:
> >>
> >> PR #6503. Turned out to be trivial.
> >>
> >> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu  wrote:
> >>>
> >>> Not yet, still building locally. My computer's slow. There's one
> problem
> >>> that's apparent though. Here's an existing test in the repo:
> >>>
> >>> ```
> >>> LiteralsTestSuite.test("image") {
> >>>   let image = #imageLiteral(resourceName: NSImageNameComputer)
> >>>   expectTrue(image.isValid)
> >>> }
> >>> ```
> >>>
> >>> Unfortunately, although `NSImageNameComputer` is a constant, it's of
> type
> >>> `String`. And tweaking global Obj-C bridging rules so that `NSString *
> >>> const` comes through as `StaticString` is just not gonna happen,
> because of
> >>> all the things you'd break. We'll lose this (kinda useful) use of
> >>> #imageLiteral unless someone goes ahead and manually bridges the
> >>> NSImageName* constants, which is acceptable, I suppose. That someone
> would
> >>> have to be the Foundation team, because Foundation APIs aren't really
> >>> subject to Evolution.
> >>>
> >>>
> >>> On Wed, Dec 28, 2016 at 4:29 PM, Micah Hainline
> >>>  wrote:
> 
>  Do you have it checked in somewhere I can see it?

Re: [swift-evolution] URL Literals

[Micah Hainline via swift-evolution]

I think that's all doable. I'm not sure what delimiters would be the
best though, which is why I hadn't moved away from #url yet. I've been
thinking hard about the regex, which seems like an even stronger case
to make into a literal, and /abc/ works well for those, but even those
have some problems, as an empty regex (valid according to
NSRegularExpression) of // would parse also as a comment. For < and >
it could start getting confusing with overloaded operators. I think it
would work, but could be a little trickier than it seems like on first
blush.

It would be easier to lex if it were expressed like
#url, but ease of lexing probably doesn't weigh
that heavily. If we wanted to do more than string, url, and regex we'd
start running out of delimiters fast though...

Another idea (taking from ruby a little) would be to have something
like %url{https://example.com} and %regex{my/regex}

In ruby, their %r{} structure can take things other than {} as long as
they don't appear in the string (for instance %r@my/regex@ works too),
we could do something like that and have a pretty robust structure for
whatever literals we wanted going forward, and it should work for url
and regex, which are in the more immediate future. Of course, % could
just as easily be #.



On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu  wrote:
> Micah,
>
> I think I'm coming round to your line of thinking re URL literals. It'd be
> nice to have them supported first-class, not like image literals (the design
> for which is really geared towards playgrounds and is rather hacky, IMO),
> but like strings. In that scenario, Foundation URL would conform to
> ExpressibleByURLLiteral. URL could even be the default URLLiteralType once
> Foundation is imported (just like String is the default StringLiteralType).
>
> What'd be _really_ nice, though, is to solidify the first-class status of
> URL literals by their spelling: not `#urlLiteral(resourceName: "blahblah")`
> or even `#url("blahblah")`, but just as you write `let str = "this is a
> string"` (and I'm sure we'll have `let regex = /foo/`), we should have `let
> url = `. The compiler would ensure that what's between
> the delimiters is a valid relative or absolute URL, and `init(urlLiteral:)`
> will get a parsed tuple just as the official standard outlines, with scheme,
> username, password, host, port, cannot-be-a-base-URL flag, path, query,
> fragment all ready to go. Looking through the lexer, it seems like this
> _should_ be possible and not inordinate amounts of work. Any thoughts about
> this idea, since you're actively studying the lexer?
>
> Xiaodi
>
>
> On Wed, Dec 28, 2016 at 5:18 PM, Xiaodi Wu  wrote:
>>
>> PR #6503. Turned out to be trivial.
>>
>> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu  wrote:
>>>
>>> Not yet, still building locally. My computer's slow. There's one problem
>>> that's apparent though. Here's an existing test in the repo:
>>>
>>> ```
>>> LiteralsTestSuite.test("image") {
>>>   let image = #imageLiteral(resourceName: NSImageNameComputer)
>>>   expectTrue(image.isValid)
>>> }
>>> ```
>>>
>>> Unfortunately, although `NSImageNameComputer` is a constant, it's of type
>>> `String`. And tweaking global Obj-C bridging rules so that `NSString *
>>> const` comes through as `StaticString` is just not gonna happen, because of
>>> all the things you'd break. We'll lose this (kinda useful) use of
>>> #imageLiteral unless someone goes ahead and manually bridges the
>>> NSImageName* constants, which is acceptable, I suppose. That someone would
>>> have to be the Foundation team, because Foundation APIs aren't really
>>> subject to Evolution.
>>>
>>>
>>> On Wed, Dec 28, 2016 at 4:29 PM, Micah Hainline
>>>  wrote:

 Do you have it checked in somewhere I can see it?

 On Wed, Dec 28, 2016 at 2:51 PM, Xiaodi Wu  wrote:
 > I may be wrong, but I think I've fixed it. Will test and make sure.
 >
 > On Wed, Dec 28, 2016 at 3:22 PM, Xiaodi Wu 
 > wrote:
 >>
 >> Well, let's stop that :)
 >>
 >>
 >> On Wed, Dec 28, 2016 at 3:21 PM, Micah Hainline
 >> 
 >> wrote:
 >>>
 >>> Yep, compiles, runs, no warnings or errors and the program displays
 >>> the expected results.
 >>>
 >>> On Wed, Dec 28, 2016 at 2:12 PM, Micah Hainline
 >>>  wrote:
 >>> > Good question. It certainly compiles, but I've stuck it in an
 >>> > out-of-the-way spot, I'll need to create a test project to know
 >>> > the
 >>> > answer to that. Just FYI: https://bugs.swift.org/browse/SR-3504
 >>> >
 >>> >
 >>> > On Wed, Dec 28, 2016 at 2:11 PM, Xiaodi Wu 
 >>> > wrote:
 >>> >> Does it run?
 >>> >>
 >>> >> On Wed, Dec 28, 2016 at 3:10 PM, Micah Hainline
 >>> >>