Presencable Protocol

[dimpiax (Dmytro Pylypenko)]

@sveinhal

Sure, and here you are force unwrapping.

The same, in the other way:

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

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

[DevAndArtist (Adrian Meister)]

@dimpiax

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

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

[dimpiax (Dmytro Pylypenko)]

Did you try it?

[DevAndArtist (Adrian Meister)]

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!
  }
}

[dimpiax (Dmytro Pylypenko)]

Calm down

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

[DevAndArtist (Adrian Meister)]

@dimpiax

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. ;)

[dimpiax (Dmytro Pylypenko)]

The example with overriding ‘first’ more brainstorming than proposition for final implementation. So there is no case to try fight for “religion” ;)

[SDGGiesbrecht (Jeremy David Giesbrecht)]

@DevAndArtist

I'm not a native English speaker and it's the first time I ever encountered the Presencable and Emptiable words, which read and sound very strange to me. In that sense I don't think they are intuitive for anyone to discover them quickly.

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).

[pyrtsa (Pyry Jahkola)]

@sveinhal

@DevAndArtist

Not quite correct. You could have something like this:

extension Collection {
  var nonEmpty: NonEmpty<Self>? {
    if isEmpty { return nil }
    return NonEmpty(self[startIndex], self[index(after: startIndex)...])
  }
}

Exactly. And that returns an optional NonEmpty . And therefore the .first called on it would also be optional when chaining.

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.

[sveinhal (Svein Halvor Halvorsen)]

@pyrtsa

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

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.