
A modest proposal for optional methods in Swift protocols - ingve
https://cocoasamurai.blogspot.com/2018/08/a-modest-proposal-for-optional-methods.html
======
elpakal
Compile time errors for an optional protocol requirement defeats the purpose
of using protocols if you ask me. Why use an optional protocol at all, if the
compiler will mandate an implementation - thus not making it optional?

I believe Chris Lattner said something along the lines as well back in Swift
Evolution proposal: "They are non-sensical - how can something be a
requirement and be optional? :)"

Source - [https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mo...](https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mon-20160104/006078.html)

~~~
mapmap
I see optional protocol methods as hints to the other developer that if you
want to implement those methods, you can, the data is there.

At least that is how I use them in Obj-C, which is proving to me to be the
more flexible alternative to Swift (despite the hype that Swift is amazing in
every use case).

This roots back to one of my main problems with Swift: it doesn't adequately
support the in-code conversation between developers. For example: no header
files to quickly digest key object interfaces and concepts. The language feels
like it is optimized to solve compiler problems and point out null value bugs
at the expense of outputting joyfully easy to follow code.

~~~
Razengan
> _at the expense of outputting joyfully easy to follow code._

I disagree.

How is _" These are the requirements, oh but some of these are not really
required."_ easy to follow?

Swift does a great job of making it easy to make sense of code _at the point
of use_ , without having to keep referring back to the definitions of things.

A protocol is a set of requirements. When I see a type adopting a protocol, I
know that it must fulfill those requirements. Done. I don't need to check if
any of the requirements were optional and I don't need to check if the
conforming type implements those optional requirements.

If you need optional requirements (an oxymoron), then just break it into
ProtocolA and ProtocolB, using protocol inheritance if needed. That's what the
Standard Library does (e.g. with `Collection` and `MutableCollection` etc.)
and it works great.

Also, at runtime, I just need to see if `type is ProtocolA` or `type is
ProtocolB`. How would you check for the implementation of optional methods
within a single protocol, without basically reinventing Objective-C?

Finally, good riddance to header files! May they forever remain entombed along
with the semicolons. There are other ways to see the overview of a type.
Xcode's Symbol Navigator for one, or the Interface Assistant Editor, or you
can put in about the same effort as writing a header file to write good
documentation.

~~~
mapmap
Imagine a protocol for a download:

Required 1\. Download finishes 2\. Download fails

Optional 3\. Download progress (for updating a progress bar)

This seems legit to me. Would one really want the added overhead of having to
implement 3 as a separate protocol?

~~~
Razengan
You'd present that as `ProgressReporting` or something, because other tasks
besides a download would want to report their progress too, and indeed, the
Foundation framework already has such a protocol [0]!

In your first comment you seem to value the ability to "quickly digest key
object interfaces and concepts" but you balk at the added clarity afforded by
separating different behaviors into distinct protocols?

If by "overhead" you mean a cost to performance, worrying about it at that
level falls under premature optimization, until you're certain that the extra
protocol noticeably harms performance.

If you really insist on having a single protocol, then make `progress` an
optional computed property.

[0]
[https://developer.apple.com/documentation/foundation/progres...](https://developer.apple.com/documentation/foundation/progressreporting)

[1]
[https://developer.apple.com/documentation/foundation/progres...](https://developer.apple.com/documentation/foundation/progress)

------
adamwk
The proposal doesn't provide a motivation other than Objective-C has them. Is
there any API design that is improved by optional protocol members? It seems
to me that if you're adding optional members to implement, your protocol or
interface is too large and should be broken up.

------
JoblessWonder
I see what you did there...

~~~
sjcsjc
For those who don't, it's a clever reference to Jonathan Swift's satirical
essay

[https://en.m.wikipedia.org/wiki/A_Modest_Proposal](https://en.m.wikipedia.org/wiki/A_Modest_Proposal)

~~~
pvg
What's the clever bit?

~~~
asimpletune
Johnathan Swift wrote a famous essay called a modest proposal, that basically
suggests we should eat children, if I recall correctly. So the clever bit is
to connect the language, and this proposal, in a lateral way, by alluding to
J. Swift’s original essay.

~~~
pvg
In what way is that clever? This thing isn't satire, the allusion, such as it
is, might not even be intentional. Nobody thinks putting 'considered harmful'
in a title is clever and those things are usually about something the author
considers harmful, like the original.

~~~
JoblessWonder
I'll take another stab at explaining this to you but I'm worried you might
just be trolling.

The phrase "A Modest Proposal" is generally associated with the essay's
author, Jonathan Swift. By combining that phrase in a literal sense ("I'm
suggesting something new about how to handle option methods") with the name of
a programming language which coincidentally is the surname of the author, it
leads to a clever connection.

It would be like an article called, "Do not cast your Perls before swine"
about dynamic casting which also is a play on the common phrase, "Do not cast
your pearls before swine." [Yeah, that example kind of sucks but it was the
first thing that popped into my head.]

~~~
pvg
You need not be worried about that, I'm not trolling. I am definitely being
churlish. Yes it's associated with Johnathan Swift but nothing in the
association is in the slightest similar to the style of Swift's essay. The
names match? So what. It's still completely pedestrian. From the wikipedia
page - "In English writing, the phrase "a modest proposal" is now
conventionally an allusion to this style of straight-faced satire.". That's
just not the case here.

You're right, it would be like that hypothetical article if you both made up a
clever title involving perl and casting _and_ the modest proposal thing was
particularly clever. But it's not, so that hypothetical rather begs the
question.

