I've just joined the list (hi!) so not sure if this has been discussed in
the past.
Curious to hear if a future version of Swift might ever include some sort
of pattern-matching extended to Arrays. Maybe something like the following:
let numbers: [Int]
switch numbers {
case []:
// to m
With respect to URL specifically, that it's a Foundation type may change
the timeline as well. Various improvements to the Foundation API (and URL
in particular) have been proposed here, but if I remember correctly, the
stated goal was first to have a complete Swift version of Foundation,
preservin
Probably worth pointing out that this topic seems entirely additive. Which
means it would be at least a phase 2 proposal, if not later.
> On Dec 17, 2016, at 4:44 PM, Micah Hainline via swift-evolution
> wrote:
>
> Yes, everyone who has what they feel like is a solid workable solution should
Yes, everyone who has what they feel like is a solid workable solution should
write it up for URL and we can compare and pick holes in them all until we get
something really solid.
> On Dec 17, 2016, at 3:27 PM, David Sweeris wrote:
>
>
>
> Sent from my iPhone
>
>> On Dec 17, 2016, at 13:20
Sent from my iPhone
> 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 shows what a complete
>> implementation of that specia
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 shows what a complete
> implementation of that special init method would look like.
I can't do it now, but I'll try post one before tomorrow t
> On Dec 17, 2016, at 11:15, Anton Zhilin wrote:
>
> I was in the process of writing something along those lines :)
>
> But I would prefer this attribute to be added implicitly by the compiler.
> Then, if we want to validate that some function is statically computable, we
> add @pure to the fu
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
I was in the process of writing something along those lines :)
But I would prefer this attribute to be added implicitly by the compiler.
Then, if we want to *validate* that some function is statically computable,
we add @pure to the function.
If we want to *require* that some variable is computed
Sent from my iPhone
> On Dec 17, 2016, at 09:47, Xiaodi Wu via swift-evolution
> wrote:
>
> I was thinking of even more explicitly venturing into `constexpr` territory
> by allowing particular initializers and functions to be marked as
> `@constantExpression` (or however you want to call it
I suppose if compile time validation is desired I guess we can do something
similar to @ibdesignables. Except instead of live rendering UIViews we
would render the url
Marking a URL like this
@urlvalidation("a URL string")
Would make it fire a compiletime URL request and give a warning if it was
It would be a good idea for literals of different types to be easily
recognizable in the source by human readers and extractable from the source
by tools. I'm sure everyone agrees that it's annoying/risky when you can't
even distinguish localizable strings (user messages) from non-localizable
strin
+1. What Tony outlined is exactly in the realm of what I had in mind.
I was thinking of even more explicitly venturing into `constexpr` territory
by allowing particular initializers and functions to be marked as
`@constantExpression` (or however you want to call it) when they use a
restricted subs
I like the David Sweeris idea best. The syntax is cleaner and the type URL
"knows what to do with itself".
let url: URL = "https://example.com";
I have strong reservations about hard-coded URLs as an SDLC 🚂 wreck waiting to
happen, but the world of mid-day build and deploy might mitigate this,
+1. Tony’s static evaluation idea also crossed my mind when reading this
thread.
> On Dec 17, 2016, at 10:52 AM, Tony Allevato via swift-evolution
> wrote:
>
> If folks want to go down this path, it:
>
> * shouldn't require compiler magic
> * shouldn't be restricted to specific types
> * sho
If folks want to go down this path, it:
* shouldn't require compiler magic
* shouldn't be restricted to specific types
* should be something that anyone can take advantage of in types that they
write.
The most general approach that jumps immediately to my mind is letting
users write code in a res
Sent from my iPhone
> On Dec 16, 2016, at 12:46, Micah Hainline via swift-evolution
> wrote:
>
> 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";)!
Do you have a treatment in mind?
Perhaps the compiler recognizes types/initializers it can check at compile time
(how?). Then it could synthesize non-failable initializers.
Or would the author write a non-failable init with some type of annotation that
the parameters must be literals? (Here I
18 matches
Mail list logo
