From 49d4893ef6cca689f811157b01733f00c9da0774 Mon Sep 17 00:00:00 2001 From: Ben Rimmington Date: Thu, 2 Jul 2020 14:49:47 +0100 Subject: [PATCH] Remove BooleanType from docs/StdlibRationales.rst --- docs/StdlibRationales.rst | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/StdlibRationales.rst b/docs/StdlibRationales.rst index 3b8503b5a92c8..1a13f5a8109c4 100644 --- a/docs/StdlibRationales.rst +++ b/docs/StdlibRationales.rst @@ -174,21 +174,6 @@ call an API with a different name, say ``lazyEnumerate()`` to opt into laziness. The problem is that the eager API, which would have a shorter and less obscure name, would be less efficient for the common case. -Use of ``BooleanType`` in library APIs --------------------------------------- - -Use ``Bool`` instead of a generic function over a ``BooleanType``, unless there -are special circumstances (for example, ``func &&`` is designed to work on all -boolean values so that ``&&`` feels like a part of the language). - -``BooleanType`` is a protocol to which only ``Bool`` and ``ObjCBool`` conform. -Users don't usually interact ``ObjCBool`` instances, except when using certain -specific APIs (for example, APIs that operate on pointers to ``BOOL``). If -someone already has an ``ObjCBool`` instance for whatever strange reason, they -can just convert it to ``Bool``. We think this is the right tradeoff: -simplifying function signatures is more important than making a marginal -usecase a bit more convenient. - Possible future directions ==========================