Presencable Protocol

The same, in the other way:

extension Collection {
    var first: Element {
        return first!
    }
}

if let value = a?.presence {
  value.first // 1, not Optional(1)
}

This extension is impossible. You cannot have an optional a non-optional property on the same type.

Did you try it?

I tried this example and got a result as I'd expect it. (edited)

protocol P {
  var test: Int? { get }
}

extension P {
  var test: Int? {
    return nil
  }
  // error: Invalid redeclaration of 'test'
  var test: Int {
    return test!
  }
}

Calm down :joy:

Did you try that example extension?
Strange that it compiles of course, but in playground it is.

I tried your explicit extension and yes it does compile. I think it's an unhandled bug, see the example with P protocol. I filed a bug report for you: [SR-9812] Disallow shadowing optional protocol members from user extensions Ā· Issue #52232 Ā· apple/swift Ā· GitHub

To add on this, we absolutely want to be able to satisfy protocol requirements of optional members with non-optional implementation on types that conform to the protocol (see this post), but I think in your case you found a compiler bug since it allowed you to shadow a protocol member.


And to be crystal clear with everyone in public, I sincerely apologize if I got a little too heated in this thread. ;)

1 Like

The example with overriding ā€˜first’ more brainstorming than proposition for final implementation. So there is no case to try fight for ā€œreligionā€ ;)

I am a native English speaker, and that is correct. I had to look at the implementations to figure out what they were supposed to mean.

Presence is a noun, not a verb, so it does not naturally combine with the suffix -able. If it were a word, it would need to retain the e, (presenceable) since changing the following vowel would imply a switch from a /s/ sound to a /k/ sound. My eyes trip over presencable, parsing it first as some sort of compound word: presen‐cable, then they regroup and parse it is a typo for pre‐sinkable. Flipping through the thesaurus suggests something like one of these might be better:

  • protocol Substantiable & var substance: Self?
  • protocol Abstract & var concrete: Self?
  • protocol Realizable & var realized: Self?
  • protocol Ignorable & var relevance: Self?
  • protocol Container & var contents: Self?

But they are all still very abstract.

Emptiable is a reasonable grammatical construct, but it implies this:

mutating func empty()

A pail is emptiable because you can dump it out (i.e. you can empty it), not because it might be empty when you find it.

protocol Container is probably the best English noun to describe this (though protocol PossiblyEmpty would be an abundantly clear alternative).

4 Likes

I think you're making a slight mistake here, Svein. What you say is correct, the type of things.nonEmpty?.first would be of optional type Element?.

However, as soon as you unwrap things.nonEmpty with an if let or guard let, you'll get nicely rid of that Optional wrapping, leaving you with a non-optional NonEmpty collection, with non-optional first and .min() and such:

guard let things = things.nonEmpty else { ... }
things.first  // <- not Optional!

I don't think the discussed pitch is fit for the standard library. I've been using the simple Collection extension of var nonEmpty: Self? which has been useful with ad hoc parsing or input validation code at times, but even that convenience might not cross the bar for inclusion in Swift. The swift-nonempty library does seem useful.

I’m not mistaken. In fact, this is exactly my point you’re making. The example given was a chain, and used first, and claimed that the presence stuff would make the chained call to first non-optional. It will not.

As I said, we need better justification and examples of use cases. So far, the only suggested use cases are either logically impossible, or just move the guard one dot up.

To have a NonEmpyCollection probably has some merit, but is orthogonal to the whole Presencable stuff.

5 Likes