The same, in the other way:
extension Collection {
var first: Element {
return first!
}
}
if let value = a?.presence {
value.first // 1, not Optional(1)
}
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
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. ;)
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).
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 think you're making a slight mistake here, Svein. What you say is correct, the type of
things.nonEmpty?.first
would be of optional typeElement?
.However, as soon as you unwrap
things.nonEmpty
with anif let
orguard let
, you'll get nicely rid of thatOptional
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.