[Discussion] Rename BitwiseOperations protocol


(Riley Testut) #1

Hi all,

This is probably very minor, but I’m not sure the protocol name “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what the guidelines have to say about protocol names:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

From these two, BitwiseOperations appears to be (attempting) to follow the first rule, yet “BitwiseOperations” doesn’t really describe what the type is, but rather that it can do bitwise operations. The documentation itself even describes the protocol as “a type that supports standard bitwise arithmetic operators."

I propose we rename it to “BitwiseOperable”, or something similar. Again, a small change, but if this were to ever happen, I think Swift 3 is the time.

Riley Testut


(Dave Abrahams) #2

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

···

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

Hi all,

This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."

I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.

--
Dave


#3

I am still curious why the SE-0104 FixedWidthInteger protocol uses member
functions like “.xor” rather than operators for bitwise manipulation.

Nevin

···

On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g.
Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.

BitwiseOperations should really be retired after

https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

--
Dave

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


(Max Moiseev) #4

FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.

I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.

As for renaming it, how about BitwiseOperand?

protocol BitwiseOperand {
  func bitwiseOr(_ rhs: Self) -> Self
  func bitwiseAnd(_ rhs: Self) -> Self
  // etc ...
}

Max

···

On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

Hi all,

This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."

I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

--
Dave

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


(Chris Lattner) #5

I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.

The global operators are implemented in terms of those methods in the protocol.

-Chris

···

On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

Nevin

On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

--
Dave

_______________________________________________
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


(Jordan Rose) #6

Option sets use set notation, not bitwise notation, no?

Jordan

···

On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution <swift-evolution@swift.org> wrote:

FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.

I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.

As for renaming it, how about BitwiseOperand?

protocol BitwiseOperand {
func bitwiseOr(_ rhs: Self) -> Self
func bitwiseAnd(_ rhs: Self) -> Self
// etc ...
}

Max

On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

Hi all,

This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."

I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

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


(Riley Testut) #7

Wasn't there a proposal to stop defining methods in addition to global operators? I would very much support that, doesn't make sense to me to have two ways to do the same thing IMO.

···

On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.

The global operators are implemented in terms of those methods in the protocol.

-Chris

Nevin

On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

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

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


(Max Moiseev) #8

OptionSets do conform to AlgebraSet but they require raw value type to conform to BitwiseOperations.

Max

···

On Jul 6, 2016, at 3:44 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Option sets use set notation, not bitwise notation, no?

Jordan

On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution <swift-evolution@swift.org> wrote:

FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.

I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.

As for renaming it, how about BitwiseOperand?

protocol BitwiseOperand {
func bitwiseOr(_ rhs: Self) -> Self
func bitwiseAnd(_ rhs: Self) -> Self
// etc ...
}

Max

On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:

Hi all,

This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."

I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

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


(Chris Lattner) #9

Yes, it will hopefully be coming back for discussion in the next week:

-Chris

···

On Jul 3, 2016, at 1:53 PM, Riley Testut <rileytestut@gmail.com> wrote:

Wasn't there a proposal to stop defining methods in addition to global operators? I would very much support that, doesn't make sense to me to have two ways to do the same thing IMO.

On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.

The global operators are implemented in terms of those methods in the protocol.

-Chris

Nevin

On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.

BitwiseOperations should really be retired after
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
is implemented, and its uses replaced by FixedWidthInteger.

--
Dave

_______________________________________________
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 <mailto: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


(Xiaodi Wu) #10

Another use case: I've got a BitArray that makes sense to conform to
BitwiseOperations, but it definitely isn't a FixedWidthInteger.

···

On Wed, Jul 6, 2016 at 17:56 Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote:

OptionSets do conform to AlgebraSet but they require raw value type to
conform to BitwiseOperations.

Max

> On Jul 6, 2016, at 3:44 PM, Jordan Rose <jordan_rose@apple.com> wrote:
>
> Option sets use set notation, not bitwise notation, no?
>
> Jordan
>
>> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> FixedWidthInteger only handles the implementation for the numbers, we
should also consider OptionSet.
>>
>> I think we should keep the protocol in case someone wants to implement
their own type other than an integer to be used as a raw value type in the
OptionSet.
>>
>> As for renaming it, how about BitwiseOperand?
>>
>> protocol BitwiseOperand {
>> func bitwiseOr(_ rhs: Self) -> Self
>> func bitwiseAnd(_ rhs: Self) -> Self
>> // etc ...
>> }
>>
>> Max
>>
>>> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>>
>>> on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> This is probably very minor, but I’m not sure the protocol name
>>>> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>>>> the guidelines have to say about protocol names:
>>>>
>>>> Protocols that describe what something is should read as nouns (e.g.
Collection).
>>>>
>>>> Protocols that describe a capability should be named using the
>>>> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>>>>
>>>> From these two, BitwiseOperations appears to be (attempting) to follow
>>>> the first rule, yet “BitwiseOperations” doesn’t really describe what
>>>> the type is, but rather that it can do bitwise operations. The
>>>> documentation itself even describes the protocol as “a type that
>>>> supports standard bitwise arithmetic operators."
>>>>
>>>> I propose we rename it to “BitwiseOperable”, or something
>>>> similar. Again, a small change, but if this were to ever happen, I
>>>> think Swift 3 is the time.
>>>
>>> BitwiseOperations should really be retired after
>>>
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>> is implemented, and its uses replaced by FixedWidthInteger.
>>>
>>> --
>>> 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
>

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