I feel that this thread has reached the predictable consensus conclusion that
we should not eliminate tuples.
Perhaps we could limit further discussion here to the idea the original poster
put forth about eliminating mixed named and unnamed tuple labels.
> On Jan 8, 2017, at 12:23 PM, Tony Alle
+1. Well thought out, it's bothered me too.
> On Jan 4, 2017, at 7:34 PM, Rick Mann via swift-evolution
> wrote:
>
> +1
>
>> On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution
>> wrote:
>>
>> Hi all,
>>
>> Here’s a draft proposal to limit inference of @objc to only those places
ow
>>>> >>> > the
>>>> >>> > answer to that. Just FYI: https://bugs.swift.org/browse/SR-3504
>>>> >>> >
>>>> >>> >
>>>> >>> > On Wed, Dec 28, 2016 at 2:11 PM, Xiaodi Wu
>>>
obably not right for this list, so I'll take them into a
bug instead.
On Wed, Dec 28, 2016 at 1:36 PM, Xiaodi Wu wrote:
> On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via swift-evolution
> wrote:
>>
>> > SE-0039 says that resourceName should be a static-string-litera
d to ask it!
On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu wrote:
> On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via swift-evolution
> wrote:
>>
>> As an aide to learning I've been playing around with implementation of
>> some of these concepts in the compiler and a
As an aide to learning I've been playing around with implementation of
some of these concepts in the compiler and a few things popped up that
I'm not happy with.
First, regarding the way #fileLiteral works, it necessitates the
addition of URL.init(fileReferenceLiteralResourceName:) which takes a
s
You haven't really explained what problem this solves, and it would have to be
a pretty big one to justify such a change.
I'm -1 on this, until a compelling argument is made. This feels like just
liking the syntax of another language and wanting it in Swift.
> On Dec 28, 2016, at 5:09 AM, Anton
I'd prefer the placement at the very end, I do think it would improve
readability, especially when taking closures as parameters and returning
closures. However, I don't think the value would be worth the cost of breaking
existing code. At the least if this were to go forward I would think we'd
like something that’s better done
> explicitly. Perhaps it’s better to think about how to reduce the boiler plate
> code, e.g. better default initializers.
>
> (this is of course, additive and beyond the current scope of Swift 4 phase 1
> planning)
>
>> On Dec 22, 2016,
Currently we allow declarations of a new class in local scope, but
nothing can be referenced from the outer scope. Thus this is illegal:
```
func foo() {
let widgetString: String = createWidgetString()
class SimpleProvider: WidgetStringProvider {
func provideWidgetString() -> String {
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
oted that `let url = URL(string: "http://example.com/";)!`
>> is one example of this usage, but not at all the only one. I have
>> previously written, for example, `"L".cString(using: .utf8)!`. This is also
>> no code smell, as what I'm doing is stating m
; On Dec 17, 2016, at 13:20, David Sweeris wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution
>>> wrote:
>>>
>>> I'd love a fleshed out elegant example for URL that
So here are some thoughts. I like the idea of an annotation for compile-time
validation, though I haven't given up on simple #url yet either. For the people
interested in @pure for its implications for functional programming, I'm
questioning if that concept sufficiently limits the problem when y
never fail, then `!` is an expressive, clear, concise, entirely
>>>>> appropriate, and I would even say the *best* way of indicating that to
>>>>> your reader.
>>>>>
>>>>> It should be noted that `let url = URL(string: "http://examp
`"L".cString(using: .utf8)!`. This is also no code
>>> smell, as what I'm doing is stating my absolute confidence (and indicating
>>> that confidence to the reader) that the letter L can be encoded using UTF-8.
>>>
>>>> but it's
ing
> that confidence to the reader) that the letter L can be encoded using UTF-8.
>
>> but it's not the best to have to say "except for URLs". I realize the
>> utility of the proposed change is reasonably small, but I also think it's
>> purely additive
also think it's purely additive and consistent with the rest of the
language. 🙂
> On Dec 16, 2016, at 6:45 PM, Xiaodi Wu wrote:
>
>> On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution
>> wrote:
>> True, but it's not at all about brevity, it's a
ca Sadun wrote:
>
> Take a peek at this:
> https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c
>
> --E
>
>> On Dec 16, 2016, at 2:58 PM, Micah Hainline via swift-evolution
>> wrote:
>>
>> Charles,
>>
>> There's already s
)!
>
> let url = #url("https://example.com";)
>
> Are not that different in length. It really isn't saving you much.
>
> I suppose you can try overloading an operator to get something to the effect
> you want.
>> On Fri, Dec 16, 2016 at 6:19 PM Micah
Exactly! It's not an earth-shattering pain, but it would be nice to have clean
type safety there.
> On Dec 16, 2016, at 4:01 PM, Charlie Monroe wrote:
>
>
>>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution
>>> wrote:
>>>
>>&g
k fine for file URLs, just not for
turning file paths INTO URLs.
On Fri, Dec 16, 2016 at 3:05 PM, Charles Srstka
wrote:
>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution
>> wrote:
>>
>> I would like to be able to create a URL literal that is compile-
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 = URL(string: "https://example.com";)!
The cleanest way I can think of doing that would be to introduce a new
macro structure similar to #selecto
23 matches
Mail list logo
