#available has a huge anti-pattern

But isn't it exactly across platforms that feature detection is the most important?

Félix

···

Le 3 févr. 2016 à 16:03:28, Douglas Gregor <dgregor@apple.com> a écrit :

On Feb 3, 2016, at 1:02 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@yahoo.ca>> wrote:

Won't it be a concern with a cross-platform Swift?

#available is currently only implemented for Apple platforms. If someone wants to extend it to another platform, they need to do so in a manner that gives it consistent semantics.

  - Doug

Félix

Le 3 févr. 2016 à 15:47:15, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Feb 3, 2016, at 5:10 AM, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Using function availability has proven fragile in the past too. A function may be present but private on older system, and have a slightly different behavior or crash, and so should not be used.

This is a failing of the -respondsToSelector: idiom for checking availability. Swift’s #available feature checks the actual OS version, so it doesn’t suffer from this problem.

  - Doug

Le 2 févr. 2016 à 11:03, James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Coming from a web background (before my iOS career) to me #avaliable has huge problem. It encourages fragility.

In my eyes we should encourage two types of detection: Features to make code more adaptable to different environments and language version detection: so we can understand the actual code.

See this example below:

func magic(object: Object)
{
  if(#avaliable(9.0, 10))
{
  object.foo()
}
}

Ideally for me I would love to check if the foo function exists like so:

func iOS9OnlyProtocolFunction(object: Object)
{
  if(#avaliable(Object.foo))
{
    object.foo()
}
else
{
  object.baz()
}
}

I think this encourages feature detection which results in less fragile code. What I would love to do is also to extend this to extensions so we could encourage polyfills.

extend object where not_avaliable(Object.foo)
{
  func foo()
{
   //Polyfill for platforms which don't support the Object.foo method
}
}

Not sure about compiler details but being able to polyfill the function results in much cleaner code for me. I love this approach from the web, so I created my own Objective-C Library to do this:

GitHub - jcampbell05/Polly: Polyfills for iOS
___________________________________

James⎥Lead Engineer

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >>>>>

10 Finsbury Square

London

>>>>> EC2A 1AF

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution