[Review] SE-0006 Apply API Guidelines to the Standard Library

Evolution Announcements
41

This is interesting, but the word "like" really weakens the semantic
implications of the protocol, which as I mentioned to Erica is really
important. The Index of my Dictionary isn't just "like" a forward
index, it *is-a* forward index.

···

on Fri Jan 29 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they
should arguably be -able protocols (BitwiseOperationsType ->
BitwiseOperable).

--
-Dave

42

Speaking of memory allocation, another improvement I would like is to allow allocation of **at least** `capacity` elements where the actual capacity of the buffer is part of the return value(s).

Given that dynamic allocators generally work with a fixed set of block sizes (buckets, pages, ...) it seems to make sense to expose this. ManagedBuffer already works this way.

For example you can use `malloc_good_size()` on Darwin to implement this. With the current static function on `UnsafeMutablePointer` you can simply return a tuple with the Pointer and actual capacity but an initializer directly precludes this. OTOH `UnsafeMutableBufferPointer` could support this even more elegantly and a hypothetical future component could probably also easily support this.

- Janosch

43

My pleasure, truly.

···

on Tue Feb 02 2016, Janosch Hildebrand <jnosh-AT-jnosh.com> wrote:

Anyway, thanks a lot for taking the time!

--
-Dave

44

I'm generally in favor of the proposed changes. I'll just note some
minor points and disagreements:

* Like I mentioned in my SE-0023 review, I would be OK with keeping

the "Type" suffix for protocols but have no strong preference.

* I'm in favor of keeping `precondition()`. `require()` might be
easier to grasp at first but personally I really came to like
`precondition()`.
It fells both precise and I prefer the passive `precondition()` to the
active `require()` for this case. To me it fits the primary meaning
better; stating an API contract. The fact that the condition is
actively checked is secondary to that.

* I also agree with Radosław in that I prefer `removeAll(keepCapacity:
Bool)` to `removeAll(keepingCapacity: Bool)`.

Why?

I had a hard time justifying "keeping" to myself for a while, but
eventually I realized that this pattern is less ambiguous, at least in
general, since many verbs are also nouns. Okay, "keeps" haven't been
considered high-tech construction elements since the middle ages, but
it's easy to understand how you'd be interested in the capacity of a
keep.

Why not, though? adding `-ing`s in this context has all of the
problems -ed/-ing has with method names,

Which problems, sorry?

A bit of extra spelling gymnastics… Maybe I’m the only one bothered by
this, but I’d just prefer a shorter/simpler name in absence of a
compelling reason to do otherwise. (You did make an argument for why
in a later post, fwiw. I’m not super compelled by it, but also don’t
feel so strongly against the `ing` to argue further ;) )

and none of the necessity of conveying mutability information.

What’s wrong with “keepCapacity” as a parameter name?

It can be interpreted as denoting the capacity of the keep.

Wow, that… would have never crossed my mind ;)

It's a terribly anachronistic example, but it's not hard to think of
others that aren't so terrible.

···

on Tue Feb 02 2016, Radosław Pietruszewski <swift-evolution@swift.org> wrote:

* What is the rationale for moving `unsafeUnwrap` into Optional but
not `unsafeAddressOf` into AnyObject?

Language limitation: AnyObject can't be modified or extended.

I can certainly see the safety argument against moving it but I don't
see how that would apply to `unsafeAddressOf` but not `unsafeUnwrap`?

* `EnumeratedSequence` and `Repeated` feel weird to me. They make
sense given the API guidelines and the previous `EnumerateSequence`
and `Repeat` were a bit clunky as well but these somehow feel a bit
worse... That might be wholly subjective though and I don't really
have a good suggestion. The only thing that came to mind was
`EnumerationSequence` and `Repetition` but I'm not overly fond of
those either especially not to the point of deviating from the norm...

Yes, they're a little clunky. No, I don't have any better ideas either
:-)

* This is not a disagreement but I'd be interested in hearing the
reasons for replacing Generator(Type) with Iterator(Protocol) if
someone finds the time. I can speculate of course but it's probably
easier for someone to give me a short summary :-)

I think these messages give all the details:

http://news.gmane.org/find-root.php?message_id=m2h9i4gffx.fsf%40eno.apple.com
http://article.gmane.org/gmane.comp.lang.swift.evolution/5344

* Typo:

+ public func take() -> Memory // Should be Pointee

Nice, thanks.

--
-Dave

_______________________________________________
swift-evolution mailing list
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
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

--
-Dave

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

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

--
-Dave

45

Keeping capacity is definitely better English, but it is a minor point
since a collection doesn't have a keep and therefore no confusion.

···

On Wednesday, 3 February 2016, Radosław Pietruszewski < swift-evolution@swift.org> wrote:

I'm generally in favor of the proposed changes. I'll just note some
minor points and disagreements:

* Like I mentioned in my SE-0023 review, I would be OK with keeping
the "Type" suffix for protocols but have no strong preference.

* I'm in favor of keeping `precondition()`. `require()` might be
easier to grasp at first but personally I really came to like
`precondition()`.
It fells both precise and I prefer the passive `precondition()` to the
active `require()` for this case. To me it fits the primary meaning
better; stating an API contract. The fact that the condition is
actively checked is secondary to that.

* I also agree with Radosław in that I prefer `removeAll(keepCapacity:
Bool)` to `removeAll(keepingCapacity: Bool)`.

Why?

I had a hard time justifying "keeping" to myself for a while, but
eventually I realized that this pattern is less ambiguous, at least in
general, since many verbs are also nouns. Okay, "keeps" haven't been
considered high-tech construction elements since the middle ages, but
it's easy to understand how you'd be interested in the capacity of a
keep.

Why not, though? adding `-ing`s in this context has all of the
problems -ed/-ing has with method names,

Which problems, sorry?

A bit of extra spelling gymnastics… Maybe I’m the only one bothered by
this, but I’d just prefer a shorter/simpler name in absence of a compelling
reason to do otherwise. (You did make an argument for why in a later post,
fwiw. I’m not super compelled by it, but also don’t feel so strongly
against the `ing` to argue further ;) )

and none of the necessity of conveying mutability information.

What’s wrong with “keepCapacity” as a parameter name?

It can be interpreted as denoting the capacity of the keep.

Wow, that… would have never crossed my mind ;)

* What is the rationale for moving `unsafeUnwrap` into Optional but
not `unsafeAddressOf` into AnyObject?

Language limitation: AnyObject can't be modified or extended.

I can certainly see the safety argument against moving it but I don't
see how that would apply to `unsafeAddressOf` but not `unsafeUnwrap`?

* `EnumeratedSequence` and `Repeated` feel weird to me. They make
sense given the API guidelines and the previous `EnumerateSequence`
and `Repeat` were a bit clunky as well but these somehow feel a bit
worse... That might be wholly subjective though and I don't really
have a good suggestion. The only thing that came to mind was
`EnumerationSequence` and `Repetition` but I'm not overly fond of
those either especially not to the point of deviating from the norm...

Yes, they're a little clunky. No, I don't have any better ideas either
:-)

* This is not a disagreement but I'd be interested in hearing the
reasons for replacing Generator(Type) with Iterator(Protocol) if
someone finds the time. I can speculate of course but it's probably
easier for someone to give me a short summary :-)

I think these messages give all the details:

http://news.gmane.org/find-root.php?message_id=m2h9i4gffx.fsf%40eno.apple.com
http://article.gmane.org/gmane.comp.lang.swift.evolution/5344

* Typo:

+ public func take() -> Memory // Should be Pointee

Nice, thanks.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
  -- Howard.

46

I agree with all of the small criticisms mentioned below by Radoslaw
except for the renaming of precondition() to require(). I think it is
an improvement that it describes an action now, just like assert().

Interestingly, I was the one that insisted on that change, as I felt
“precondition” was too much of a term-of-art and “require” would be more
accessible, but I am now regretting that decision. This function is not
conceptually an action; like “assert,” it's a declarative statement, and
“precondition” conveyed that aspect much better, IMO.

How about expect()? Should not have much string attached to it. Only
thing coming to mind is the
TCL extension used for automation.

That is, again, more action-y and less declarative. We could go with
"expected," of course, but in either case we're just inventing names for
something that already has a perfectly good name. Precondition is a
term of art with a precise meaning. Does anybody on this list feel that
"precondition" is too inaccessible?

···

on Tue Jan 26 2016, Dany St-Amant <swift-evolution@swift.org> wrote:

Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> a écrit :
on Tue Jan 26 2016, Charles Kissinger <swift-evolution@swift.org> wrote:

Dany

Count me among those who liked the ‘Type’ suffix for protocols though.

—CK

On Jan 25, 2016, at 7:40 AM, Radosław Pietruszewski via >>>> swift-evolution >>>> <swift-evolution@swift.org> wrote:

Hello all,

Just like with SE-0005
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007658.html&gt;,
I’m overwhelmingly for this proposal. The Guidelines, as a whole do
a great job at making Swift APIs more consistent and clearer, and
applying them to the Swift stdlib is an important first step.

* * *

Nitpicks, criticisms and suggestions:

== precondition was renamed to require ==

This might be confusing to newcomers, as many languages use the word
`require` as a keyword for what we'd call `import`. Although a bit
more technical, `precondition` is unambiguous and still easily
understandable. I feel like `required` does more damage than good.

== Removed Type from protocol names ==

Perhaps I’ve missed some discussion about this and I don’t see the
context, but I’m not sure this is a positive change.

I fear this might be confusing in practice, at least in some
contexts. For example, there's nothing signifying that "Boolean" or
"Integer" are protocols and not actual types. Same with “Sequence”,
“OptionSet”, etc. Perhaps it doesn't matter because everyone will
naturally go for `Bool`, `Int`, and `Array` anyway. But I can
imagine a lot of confusion if someone tried that anyway, or perhaps
saw that in the autocompletion, or the standard library browser
(with no intention of using the protocol).

I’m all for removing unnecessary noise and verbosity, but I think I
would err on explicitness side here. It seemed like the -able/-Type
convention did a good job disambiguating types you can actually
instantiate from protocols, with very little “verbosity cost”.

== sort() => sorted(), sortInPlace() => sort() etc ==

I’m torn on this.

Frankly, I find both the “foo/fooInPlace” and “bar/barred”
conventions awkward. Both seem weird. “InPlace” isn’t something I
recall seeing anywhere else in API naming, and seems a bizarre way
of signifying mutability. “-ed” doesn’t work with all words, so you
sometimes have to go with “-ing”, or give up and cry. And then you
have inconsistency that “-InPlace” doesn’t seem to have. Also,
-ed/-ing can sometimes be difficult to write, especially for
non-natives because of the “last letter is doubled” rule for some
words.

But my biggest problem with this change is that IMHO we should
encourage to use the transforming (non-mutating) variants by
default. One way to achieve this as an API designer and slightly
push people towards doing what’s considered best practice is to make
the preferable variant easier to type. This might be a subtle
change, but I think it matters. Before, if you really wanted to
mutate something in place, you had to do that extra little bit of
work typing “sortInPlace”, whereas what would be preferable most of
the time had a simpler, shorter form: “sort” and would appear
earlier in autocomplete.

== -ings in argument names ==

I’ve noticed these few tweaks in naming:

- mutating func removeAll(keepCapacity keepCapacity: Bool = false)
+ mutating func removeAll(keepingCapacity keepingCapacity: Bool = false)

public func transcode<...>(...
- stopOnError: Bool
+ stoppingOnError: Bool
) -> Bool

+ public init(allocatingCapacity count: Int)

I'm against this change. While I'm not fully convinced of the
-ed/-ing rule for methods and properties, it does an important job
by conveying the non-mutating semantics of a symbol described. In
case of argument names, this rationale no longer applies.

The only reason to write "stoppingOnError" instead of "stopOnError"
is to make method invocations sound more like real English
sentences. This is the conventional Objective-C thinking the
Guidelines largely step back from. In my opinion, this is futile and
provides no readability benefits in this context. Method invocations
are _not_ sentences. It's not English, it's code. And while making
method names blatantly gramatically incorrect doesn't help
readability, neither does forcing `-ing` endings to all boolean
function arguments.

The only thing it does is it adds a few extra characters, an extra
word ending the reader has to parse and understand. I know that it's
a non-goal to make Swift code as terse as possible, and I'm not
arguing for that. But the Guidelines seem to agree that adding extra
verbosity _without a good reason_ is a bad thing. Because every
extra word and symbol in code just adds to the cognitive load of the
reader. And when it doesn't serve a purpose, it just decreases the
signal-to-noise ratio.

Plus, as mentioned before, `-ed/-ing` can be tricky to spell for
non-natives. This might not be a big deal, but given that this
change provides no benefits, it's one more tiny thing you have to be
careful not to get wrong when writing Swift.

And it's unnecessary:

  removeAll(keepCapacity: true)
  transcode(foo, bar, stopOnError: true)

Are just as clear and readable as:

  removeAll(keepingCapacity: true)
  transcode(foo, bar, stoppingOnError: true)

And the former isn't gramatically incorrect, because this isn't a sentence.

Apologies for nitpicking on this tiniest possible detail. I just
care a lot that we don't create a precedent of trying to make
everything sound like English unnecessarily and add verbosity bit by
bit.

* * *

Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?

Yes, and yes, with small details still worth reconsidering.

How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I’ve read the whole proposal, as well as the related proposals, and
read the thread for this review.

Cross-linking to my SE-0005 review:
[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007658.html&gt;

Thanks,
— Radek

On 22 Jan 2016, at 22:02, Douglas Gregor via swift-evolution >>>>> <swift-evolution@swift.org >>>>> <mailto:swift-evolution@swift.org>> >>>>> wrote:

Hello Swift community,

The review of SE-0006 "Apply API Guidelines to the Standard
Library" begins now and runs through January 31, 2016. The proposal
is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md&gt;
Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
or, if you would like to keep your feedback private, directly to
the review manager. When replying, please try to keep the proposal
link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md&gt;
Reply text

Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
goes into a review?

The goal of the review process is to improve the proposal under
review through constructive criticism and, eventually, determine
the direction of Swift. When writing your review, here are some
questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
<https://github.com/apple/swift-evolution/blob/master/process.md&gt;
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

--
-Dave

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

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

--
-Dave

47

That's not bad, but to me "expect" seems more open-ended than "require" or "precondition", i.e. "if it isn't true, then what?". I don't assume that it's going to be fatal.

(It even feels a little like an optimization hint to me, like "expect(self.dynamicType === BaseClass.self)". It could still be a subclass, but the compiler would know what the common case is.)

Jordan

···

On Jan 26, 2016, at 18:06, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution <swift-evolution@swift.org> a écrit :

on Tue Jan 26 2016, Charles Kissinger <swift-evolution@swift.org> wrote:

I agree with all of the small criticisms mentioned below by Radoslaw
except for the renaming of precondition() to require(). I think it is
an improvement that it describes an action now, just like assert().

Interestingly, I was the one that insisted on that change, as I felt
“precondition” was too much of a term-of-art and “require” would be more
accessible, but I am now regretting that decision. This function is not
conceptually an action; like “assert,” it's a declarative statement, and
“precondition” conveyed that aspect much better, IMO.

How about expect()? Should not have much string attached to it. Only thing coming to mind is the
TCL extension used for automation.

48

Huh… Yeah, you’re right. I guess I saw “CollectionType” and
“CustomStringConvertible” or something and made a connection that
wasn’t there.
Well, FWIW, that convention (plus the occasional “HasNoun”, and
-ableType for constraining the element of custom collections) tends to
work well for me.

What’s been the deciding factor between -Type and -able so far?

When there's no reasonable -able or -ible name, use -Type.

···

on Wed Jan 27 2016, Dave <swift-evolution@swift.org> wrote:

- Dave Sweeris

On Jan 27, 2016, at 00:49, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

on Tue Jan 26 2016, Dave <swift-evolution@swift.org> wrote:

On Jan 25, 2016, at 07:40, Radosław Pietruszewski via >>>> swift-evolution <swift-evolution@swift.org> wrote:

== Removed Type from protocol names ==

Perhaps I’ve missed some discussion about this and I don’t see the
context, but I’m not sure this is a positive change.

I fear this might be confusing in practice, at least in some
contexts. For example, there's nothing signifying that "Boolean" or
"Integer" are protocols and not actual types. Same with “Sequence”,
“OptionSet”, etc. Perhaps it doesn't matter because everyone will
naturally go for `Bool`, `Int`, and `Array` anyway. But I can
imagine a lot of confusion if someone tried that anyway, or perhaps
saw that in the autocompletion, or the standard library browser
(with no intention of using the protocol).

I’m all for removing unnecessary noise and verbosity, but I think I
would err on explicitness side here. It seemed like the -able/-Type
convention did a good job disambiguating types you can actually
instantiate from protocols, with very little “verbosity cost”.

Same here… I like -Type for protocols that can only be used a generic
constraint, and -able/-ible for protocols that can be “concrete”
types.

But that's not how they're used. I'd have to rename Equatable and
Comparable to follow that convention.

--
-Dave

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

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

--
-Dave

49

IMO the ‘like’ suffix makes it sound like the conforming type to Collectionlike is like a Collection, but not exactly a Collection.

and isn't this the point of protocols? To decouple the behaviour you expose/the contract you make from what you actually are/how you are implemented?

···

On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution <swift-evolution@swift.org> wrote:

Maybe there’s another suffix that works but I don’t think this one conveys the right information.

- Alex

On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they should arguably be -able protocols (BitwiseOperationsType -> BitwiseOperable).

--
Brent Royal-Gordon
Architechies

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

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

50

I still don’t see why we need a suffix at all, what is unclear about the CollectionType protocol simply being called Collection instead? It’s declared as a protocol after all, so there’s no risk of someone accidentally instantiating one.

···

On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution <swift-evolution@swift.org> wrote:

IMO the ‘like’ suffix makes it sound like the conforming type to Collectionlike is like a Collection, but not exactly a Collection. Maybe there’s another suffix that works but I don’t think this one conveys the right information.

- Alex

On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they should arguably be -able protocols (BitwiseOperationsType -> BitwiseOperable).

--
Brent Royal-Gordon
Architechies

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

51

I don’t, but I do like “require”. Unlike “precondition”, “require” is straightforward language. That particular use of “precondition” isn’t necessarily “pre”-anything; nothing prevents anyone from sticking a precondition() call just before returning from a function; then it becomes a weird misnomer. I am skeptical of “term of art” as a justification, because it is nearly a synonym of “jargon”, and that is not a good thing.

Cheers,
Guillaume Lessard

···

On 27 janv. 2016, at 00:07, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Does anybody on this list feel that "precondition" is too inaccessible?

52

I agree with all of the small criticisms mentioned below by Radoslaw
except for the renaming of precondition() to require(). I think it is
an improvement that it describes an action now, just like assert().

Interestingly, I was the one that insisted on that change, as I felt
“precondition” was too much of a term-of-art and “require” would be more
accessible, but I am now regretting that decision. This function is not
conceptually an action; like “assert,” it's a declarative statement, and
“precondition” conveyed that aspect much better, IMO.

How about expect()? Should not have much string attached to it. Only
thing coming to mind is the
TCL extension used for automation.

That is, again, more action-y and less declarative. We could go with
"expected," of course, but in either case we're just inventing names for
something that already has a perfectly good name. Precondition is a
term of art with a precise meaning. Does anybody on this list feel that
"precondition" is too inaccessible?

‘Precondition’ is not particularly bad jargon since it is a standard dictionary word that is used with a similar meaning in areas outside of computer science. ‘Require’ probably has an advantage with students and non-native English speakers by virtue of being a much more commonly used and understood word.

—CK

···

On Jan 26, 2016, at 11:07 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Tue Jan 26 2016, Dany St-Amant <swift-evolution@swift.org> wrote:

Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> a écrit :
on Tue Jan 26 2016, Charles Kissinger <swift-evolution@swift.org> wrote:

Dany

Count me among those who liked the ‘Type’ suffix for protocols though.

—CK

On Jan 25, 2016, at 7:40 AM, Radosław Pietruszewski via >>>>> swift-evolution >>>>> <swift-evolution@swift.org> wrote:

Hello all,

Just like with SE-0005
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007658.html&gt;,
I’m overwhelmingly for this proposal. The Guidelines, as a whole do
a great job at making Swift APIs more consistent and clearer, and
applying them to the Swift stdlib is an important first step.

* * *

Nitpicks, criticisms and suggestions:

== precondition was renamed to require ==

This might be confusing to newcomers, as many languages use the word
`require` as a keyword for what we'd call `import`. Although a bit
more technical, `precondition` is unambiguous and still easily
understandable. I feel like `required` does more damage than good.

== Removed Type from protocol names ==

Perhaps I’ve missed some discussion about this and I don’t see the
context, but I’m not sure this is a positive change.

I fear this might be confusing in practice, at least in some
contexts. For example, there's nothing signifying that "Boolean" or
"Integer" are protocols and not actual types. Same with “Sequence”,
“OptionSet”, etc. Perhaps it doesn't matter because everyone will
naturally go for `Bool`, `Int`, and `Array` anyway. But I can
imagine a lot of confusion if someone tried that anyway, or perhaps
saw that in the autocompletion, or the standard library browser
(with no intention of using the protocol).

I’m all for removing unnecessary noise and verbosity, but I think I
would err on explicitness side here. It seemed like the -able/-Type
convention did a good job disambiguating types you can actually
instantiate from protocols, with very little “verbosity cost”.

== sort() => sorted(), sortInPlace() => sort() etc ==

I’m torn on this.

Frankly, I find both the “foo/fooInPlace” and “bar/barred”
conventions awkward. Both seem weird. “InPlace” isn’t something I
recall seeing anywhere else in API naming, and seems a bizarre way
of signifying mutability. “-ed” doesn’t work with all words, so you
sometimes have to go with “-ing”, or give up and cry. And then you
have inconsistency that “-InPlace” doesn’t seem to have. Also,
-ed/-ing can sometimes be difficult to write, especially for
non-natives because of the “last letter is doubled” rule for some
words.

But my biggest problem with this change is that IMHO we should
encourage to use the transforming (non-mutating) variants by
default. One way to achieve this as an API designer and slightly
push people towards doing what’s considered best practice is to make
the preferable variant easier to type. This might be a subtle
change, but I think it matters. Before, if you really wanted to
mutate something in place, you had to do that extra little bit of
work typing “sortInPlace”, whereas what would be preferable most of
the time had a simpler, shorter form: “sort” and would appear
earlier in autocomplete.

== -ings in argument names ==

I’ve noticed these few tweaks in naming:

- mutating func removeAll(keepCapacity keepCapacity: Bool = false)
+ mutating func removeAll(keepingCapacity keepingCapacity: Bool = false)

public func transcode<...>(...
- stopOnError: Bool
+ stoppingOnError: Bool
) -> Bool

+ public init(allocatingCapacity count: Int)

I'm against this change. While I'm not fully convinced of the
-ed/-ing rule for methods and properties, it does an important job
by conveying the non-mutating semantics of a symbol described. In
case of argument names, this rationale no longer applies.

The only reason to write "stoppingOnError" instead of "stopOnError"
is to make method invocations sound more like real English
sentences. This is the conventional Objective-C thinking the
Guidelines largely step back from. In my opinion, this is futile and
provides no readability benefits in this context. Method invocations
are _not_ sentences. It's not English, it's code. And while making
method names blatantly gramatically incorrect doesn't help
readability, neither does forcing `-ing` endings to all boolean
function arguments.

The only thing it does is it adds a few extra characters, an extra
word ending the reader has to parse and understand. I know that it's
a non-goal to make Swift code as terse as possible, and I'm not
arguing for that. But the Guidelines seem to agree that adding extra
verbosity _without a good reason_ is a bad thing. Because every
extra word and symbol in code just adds to the cognitive load of the
reader. And when it doesn't serve a purpose, it just decreases the
signal-to-noise ratio.

Plus, as mentioned before, `-ed/-ing` can be tricky to spell for
non-natives. This might not be a big deal, but given that this
change provides no benefits, it's one more tiny thing you have to be
careful not to get wrong when writing Swift.

And it's unnecessary:

removeAll(keepCapacity: true)
transcode(foo, bar, stopOnError: true)

Are just as clear and readable as:

removeAll(keepingCapacity: true)
transcode(foo, bar, stoppingOnError: true)

And the former isn't gramatically incorrect, because this isn't a sentence.

Apologies for nitpicking on this tiniest possible detail. I just
care a lot that we don't create a precedent of trying to make
everything sound like English unnecessarily and add verbosity bit by
bit.

* * *

Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?

Yes, and yes, with small details still worth reconsidering.

How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I’ve read the whole proposal, as well as the related proposals, and
read the thread for this review.

Cross-linking to my SE-0005 review:
[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007658.html&gt;

Thanks,
— Radek

On 22 Jan 2016, at 22:02, Douglas Gregor via swift-evolution >>>>>> <swift-evolution@swift.org >>>>>> <mailto:swift-evolution@swift.org>> >>>>>> wrote:

Hello Swift community,

The review of SE-0006 "Apply API Guidelines to the Standard
Library" begins now and runs through January 31, 2016. The proposal
is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md&gt;
Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
or, if you would like to keep your feedback private, directly to
the review manager. When replying, please try to keep the proposal
link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md&gt;
Reply text

Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
goes into a review?

The goal of the review process is to improve the proposal under
review through constructive criticism and, eventually, determine
the direction of Swift. When writing your review, here are some
questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
<https://github.com/apple/swift-evolution/blob/master/process.md&gt;
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

--
-Dave

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

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

--
-Dave

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

53

This is where I never know whether to keep my nose out of things or just jump in. I find there are generally two kinds of protocols: verby-ones ("this is how this thing works") and nouny-ones ("this is what this thing is"). Here's the guidance I've been giving:

Swift protocols describe the surface that connect a feature provider API with its consumer. Protocols establish a communication contract. They ensure a fit between each required member and the provider’s implementation. It’s like whether a virus can attach to a host cell’s receptors, or whatever the actual biological equivalent is. The standard library describes protocols using nouns (typically ending in Type, e.g. MirrorPathType, MutableCollectionType, ErrorType) and adjectives (typically ending in ble, like Streamable, Strideable, ArrayLiteralConvertible). The former more commonly discuss what a conforming type is and the latter what it does.

When naming a protocol, you’re not limited to Type and ble endings. Your protocol can be, for example, a DataProvider or a FloatConsumer. A protocol can describe a relationship DownloadProcessingDelegate or ListViewDataSource. You may implement an OutputDestination or an IntegerSink. The current API Design guidelines say "omit needless words", so you might prefer to go with DataProvider over DataProviderType or MirrorPath over MirrorPathType, but I wouldn't give much more constraint to naming beyond that.

For example, for "HasNoun", I'd go with something more like NounContainingType or NounSupplier.

Non-Abrahams Dave writes: "I like -Type for protocols that can only be used a generic constraint, and -able/-ible for protocols that can be “concrete” types.

And Canonical Dave replies: "But that's not how they're used. I'd have to rename Equatable and Comparable to follow that convention."

I agree in that I'm not convinced it's the role of a protocol to describe implementation details. (I'd say the same for method names, but that's different thread about mutability and side effects, etc). Going that way leads you to over-designated hungarian-esque guidelines that I'd rather keep loose, friendly, and sensible.

-- Erica

···

On Jan 27, 2016, at 11:42 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Jan 27 2016, Dave <swift-evolution@swift.org> wrote:

Huh… Yeah, you’re right. I guess I saw “CollectionType” and
“CustomStringConvertible” or something and made a connection that
wasn’t there.
Well, FWIW, that convention (plus the occasional “HasNoun”, and
-ableType for constraining the element of custom collections) tends to
work well for me.

What’s been the deciding factor between -Type and -able so far?

When there's no reasonable -able or -ible name, use -Type.

54

Someone I spoke with had a good idea about this IMO. They recommended we have debugAssert and releaseAssert (or debugRequire and releaseRequire). I think this makes the semantics obvious and has consistent terminology between the functions. There’s no question at the call site what was intended.

- Alex

···

On Jan 27, 2016, at 3:33 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 26, 2016, at 18:06, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution <swift-evolution@swift.org> a écrit :

on Tue Jan 26 2016, Charles Kissinger <swift-evolution@swift.org> wrote:

I agree with all of the small criticisms mentioned below by Radoslaw
except for the renaming of precondition() to require(). I think it is
an improvement that it describes an action now, just like assert().

Interestingly, I was the one that insisted on that change, as I felt
“precondition” was too much of a term-of-art and “require” would be more
accessible, but I am now regretting that decision. This function is not
conceptually an action; like “assert,” it's a declarative statement, and
“precondition” conveyed that aspect much better, IMO.

How about expect()? Should not have much string attached to it. Only thing coming to mind is the
TCL extension used for automation.

That's not bad, but to me "expect" seems more open-ended than "require" or "precondition", i.e. "if it isn't true, then what?". I don't assume that it's going to be fatal.

(It even feels a little like an optimization hint to me, like "expect(self.dynamicType === BaseClass.self)". It could still be a subclass, but the compiler would know what the common case is.)

55

I still don’t see why we need a suffix at all, what is unclear about the CollectionType protocol simply being called Collection instead?

They're attractive nuisances. Someone wants an integer type, sees Integer, tries to use it, and suddenly they're getting weird errors about Self and associated object requirements. Or they want a boolean variable, see Boolean, and suddenly their one-bit value is wrapped in a 40-byte protocol witness. Nobody is going to mistake Integerlike or Booleanlike for a concrete type and use it accidentally.

···

--
Brent Royal-Gordon
Architechies

56

I never liked the practice of having classes and protocols with the same name, like NSObject, although legal and maybe very reasonable at times. A protocol should express what it is, a contract.

···

Sent from my iPhone

On 30 Jan 2016, at 09:48, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I still don’t see why we need a suffix at all, what is unclear about the CollectionType protocol simply being called Collection instead? It’s declared as a protocol after all, so there’s no risk of someone accidentally instantiating one.

On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution <swift-evolution@swift.org> wrote:

IMO the ‘like’ suffix makes it sound like the conforming type to Collectionlike is like a Collection, but not exactly a Collection. Maybe there’s another suffix that works but I don’t think this one conveys the right information.

- Alex

On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they should arguably be -able protocols (BitwiseOperationsType -> BitwiseOperable).

--
Brent Royal-Gordon
Architechies

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

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

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

57

The first example (errors about Self) is more a problem with the error being confusing to new users, first time I encountered that was a real head-scratcher as I was trying to use a protocol as a type for a variable (which is still a problem with Swift really, since some can be used and others can’t). Anyway, the fact is that it returns an error; while the error may currently be hostile to new users, that’s its own problem IMO.

I’m also not sure what you mean about the overhead on BooleanType being misused as Boolean? It can’t be instantiated directly, and with that specific example I’ve never seen code that doesn’t use true/false directly anyway (or some comparison like someInt != 0). Bool doesn’t really have initialisers that need to be used much.

I suppose if we do have to have a suffix though then I would also prefer Like over Type; Type to me isn’t a good fit as not every protocol can be used as a type (due to aforementioned Self restrictions), whereas describing it as like something is essentially what a protocol does, as a struct could theoretically be IntegerLike without being backed by an integer at all.

···

On 30 Jan 2016, at 09:53, Brent Royal-Gordon <brent@architechies.com> wrote:

I still don’t see why we need a suffix at all, what is unclear about the CollectionType protocol simply being called Collection instead?

They're attractive nuisances. Someone wants an integer type, sees Integer, tries to use it, and suddenly they're getting weird errors about Self and associated object requirements. Or they want a boolean variable, see Boolean, and suddenly their one-bit value is wrapped in a 40-byte protocol witness. Nobody is going to mistake Integerlike or Booleanlike for a concrete type and use it accidentally.

58

IMO the ‘like’ suffix makes it sound like the conforming type to
Collectionlike is like a Collection, but not exactly a Collection.

and isn't this the point of protocols? To decouple the behaviour you
expose/the contract you make from what you actually are/how you are
implemented?

The point is that conforming to a protocol is supposed to be a strong
declaration about not just syntax, but semantics. You could read my
posts in this 14-year-old thread
<Carbon60: Managed Cloud Services;
(geez, now I feel ancient) if you want to understand what I mean.

···

on Sat Jan 30 2016, Goffredo Marocchi <swift-evolution@swift.org> wrote:

On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution >> <swift-evolution@swift.org> wrote:

Maybe there’s another suffix that works but I don’t think this one conveys the right information.

- Alex

On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via >>>> swift-evolution >>>> <swift-evolution@swift.org> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they
should arguably be -able protocols (BitwiseOperationsType ->
BitwiseOperable).

--
Brent Royal-Gordon
Architechies

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

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

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

--
-Dave

59

I still don’t see why we need a suffix at all, what is unclear about
the CollectionType protocol simply being called Collection instead?
It’s declared as a protocol after all, so there’s no risk of someone
accidentally instantiating one.

+1

One thing we love to do, as programmers, is set up systems of
organization that classify and categorize things. It's almost reflexive
and instinctual for many of us, and we seldom ask ourselves whether the
system of organization is pulling its weight, which is IMO why we got
code like what's shown in http://stackoverflow.com/q/321413\.

The one thing that originally pushed me toward the “Type” suffix for
protocols was the fact that we were starting to see associated types
whose names were the same as the protocols they modeled, e.g.

  associatedtype Generator : Generator

But this has in fact proven to be a rare occurrence, and just like there
are usually better names for variables than the names of their types,
there are usually better names for associated types than the names of
their protocols, e.g.

  associatedtype IterationState : Generator

···

on Sat Jan 30 2016, Haravikk <swift-evolution@swift.org> wrote:

On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution >> <swift-evolution@swift.org> wrote:

IMO the ‘like’ suffix makes it sound like the conforming type to
Collectionlike is like a Collection, but not exactly a
Collection. Maybe there’s another suffix that works but I don’t
think this one conveys the right information.

- Alex

On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via swift-evolution >>> <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> >>> wrote:

Count me among those who liked the ‘Type’ suffix for protocols though.

I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:

AnyCollectionlike
BidirectionalIndexlike
BitwiseOperationslike
Booleanlike
CVarArglike
Collectionlike
Errorlike
FloatingPointlike
ForwardIndexlike
Generatorlike
IntegerArithmeticlike
Integerlike
Intervallike
LazyCollectionlike
LazySequencelike
MirrorPathlike
MutableCollectionlike
OptionSetlike
OutputStreamlike
RandomAccessIndexlike
RangeReplaceableCollectionlike
ReverseIndexlike
Sequencelike
SetAlgebralike
SignedIntegerlike
SignedNumberlike
UnicodeCodeclike
UnsignedIntegerlike

Not all of these are perfect, but in some cases that's because they
should arguably be -able protocols (BitwiseOperationsType ->
BitwiseOperable).

--
Brent Royal-Gordon
Architechies

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

--
-Dave

60

Does anybody on this list feel that "precondition" is too inaccessible?

I don’t, but I do like “require”. Unlike “precondition”, “require” is
straightforward language.

...which is why I originally requested the change.

That particular use of “precondition” isn’t necessarily
“pre”-anything; nothing prevents anyone from sticking a precondition()
call just before returning from a function; then it becomes a weird
misnomer.

Sort of, sort of not. It happens that sometimes you can't tell that the
precondition is violated until sometime late in the function. So it may
be a surprising place to see the word "precondition," but it still can
be a precondition check.

I am skeptical of “term of art” as a justification, because it is
nearly a synonym of “jargon”, and that is not a good thing.

It *is* a synonym for "jargon," which is neither a good nor a bad thing.
Jargon exists for a reason: to allow us to communicate precisely about
topics in specialized domains. Can you imagine where we'd be if doctors
couldn't use medical jargon to describe symptoms and procedures?

···

on Tue Jan 26 2016, Guillaume Lessard <swift-evolution@swift.org> wrote:

On 27 janv. 2016, at 00:07, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

--
-Dave