Is it possible to create `and` and `or` extension for `Bool` type?

looks like it is not exactly the same as ! for some reason...

/// The `unsafelyUnwrapped` property provides the same value as the forced
/// unwrap operator (postfix `!`). However, in optimized builds (`-O`), no
/// check is performed to ensure that the current instance actually has a
/// value. Accessing this property in the case of a `nil` value is a serious
/// programming error and could lead to undefined behavior or a runtime
/// error.
/// In debug builds (`-Onone`), the `unsafelyUnwrapped` property has the same
/// behavior as using the postfix `!` operator and triggers a runtime error
/// if the instance is `nil`.
/// The `unsafelyUnwrapped` property is recommended over calling the
/// `unsafeBitCast(_:)` function because the property is more restrictive
/// and because accessing the property still performs checking in debug
/// builds.
/// - Warning: This property trades safety for performance.  Use
///   `unsafelyUnwrapped` only when you are confident that this instance
///   will never be equal to `nil` and only after you've tried using the
///   postfix `!` operator.
@inlinable public var unsafelyUnwrapped: Wrapped { get }

if only half as much attention was paid to things like making tuples conformable to protocols as to these endless discussions about the correct symbol for AND expressions,, i would happily trade Swift’s unicode support for the ability to extend and conform non-nominal types like the (Int, Int) 2D index in @tera’s other thread


I didn’t say that the familiar is correct.

I didn’t say anything about correctness. Whether or not something is correct is very different from whether or not it is familiar.

Correctness is dependent on formal definitions within a field. Within a given framework, something is objectively either true or false. If true, it is (strictly speaking) correct.

However, whether something is natural, logical* or easy, is a matter of subjectivity and familiarity. This is true whether you agree or not.

(“Logical” is somewhat elusive since it is both a formally defined term for thing within the field of logic, and also an informal word used to describe stuff that is intuitive)

The two things aren't at all related, and neither of these threads are even in Swift evolution.

After a long discussion, I may conclude that it's impossible to achieve what I want above in Swift. The only possible solution is using other symbols that are more mathematically correct, such as , , ¬, and .

Well… although it's not what I really want but I can accept and live with that. It's part of Swift limitation and it's by design. Thank you all.

Have a happy weekend, everybody.

1 Like

It was part of the motivating example for the other thread with essentially the same main participants (tera and mrbee) and essentially the same issues discussed (spelling of boolean operators)

that thread doesn't go beyond current swift abilities, thus it is not in evolution.

and in evolution we sometimes try to go beyond current limits. for example:

modern IDE's are quite capable of converting things like "#imageLiteral(resourceName: "name")" to a symbol with an image. also syntax hilting is very useful (i fill completely handicapped when it doesn't work for some reason). what if we had an ability to create operators by putting identifiers in some tick marks, for example:

operator 'and'
prefix operator 'not'

(if i remember correctly the straight apostrophe ' is not used anywhere else in the language)

then it would look like this in some ascii editor / terminal:
'not' black
black 'and' write

which is not too bad. and it will look like this in Xcode:
not black
black and white // with some prominent font selected for such operators

maybe not so useful for ! and && per se, but for custom operators can be very useful. for this i would trade swift's unicode support.

i just realised we are not in evolution :slight_smile: i thought we were.

It's not like it's one or the other. ¯_(ツ)_/¯
Plus, I don't think any of the thread related to those has ever reached an implementation phase.

Heck, unicode support for string literal is one of the best thing since slice bread, I'd trade none for that. And unicode support for syntactical portions seems to be just a nudge after that.

something like this:

prefix operator 'neg' {
symbol: "≠" // optional specification just for IDE visualizing

infix operator 'like' {
symbol: ":yellow_heart:" // optional specification just for IDE visualizing

in terminal:

a 'neq' b
i 'like' this

in Xcode when some "show operator symbols" setting is switched off:

a neq b
i like this

in Xcode when "show operator symbols" is switched on:

a b
i :yellow_heart: this

note that compared to what we have now this is purely a visual representation in IDE, at the language level no unicode support is used here (apart from using unicode inside string literals).

do you mean some concrete pitches on evolution?

somewhat useful inside string literals, yes.

that one i abstain to use. even in comments :-)

You don't need fancy IDE support, simple keyboard text-replacement will do pretty much what you're saying. Except that :yellow_heart: is not a valid operator (it's on identifier side I think?), and that's all the more reason to have unicode support!

There are tons, but most are pitching ideas, and not a lot progress to the point that someone picked it up and try to implement it for the proposal.

Non-nominal conformance

Honestly, at this point I can't even remember which thread is good. You can probably try to look it up.

I do also remember seeing a ' for escaping operator somewhere long ago, but my search-fu isn't advanced enough.

1 Like

on my book it is upside down :slight_smile: you would not need unicode support embedded into the language (in areas of the language other than using unicode inside string literals) if you do the above, and even outside of IDE quoted 'operators' will look reasonably well. as a bonus you'd be able to remove the portion of the language that deals with "identifier side vs operator side" of unicode rules (which are quite arbitrary).

that's interesting. will try to find one and see what was the outcome / reasoning.

Agree to disagree. Just that text symbol text to me reads better than text 'text' text. Also, I don't think having a source code displayable in 2 different forms is a stellar idea.

Could be a lost cause. My memory of it is vague at best. Might as well spawn a new thread and see what comes of it (after you searched the forum ofc).

that's only when viewed outside of IDE. but ok. :slight_smile:

this is the fact of life we already have to deal with.. look how imageLiterals are exposed outside of Xcode. not a deal breaker to me. e.g. this:

as one of the authors behind last year’s ASCII/character literals proposal using ' for this seems like a huge lost opportunity

1 Like

i hope you do not mean that to be "a bad thing".

the very first thing i do today when have to go to C++ is this:

#define let const auto // because "const auto" is for masochists
#define var auto

so that i can write this later:

if (let p = somePointerExpression()) {

i introduced this to my fellow C++ developers and now they are converted and can't live without it.

1 Like

this is well within language boundaries...

if i write:

func theSame(_ v: T) -> T {
return v

and use it through the codebase and a follow developer of mine asks why, and i explain, for example, "so that i can put a breakpoint", or give another explanation - it's totally fine with the developer. he will either use this as well, or not use it, in either case there will be no conflict.

ditto for a custom operator <>

you only really "change the language" when you go inside swift compiler source code, modify it, and force others to use your version :-) until then whatever you do is a mere "fair usage".

and the very second thing i do when have to go to C/C++ are typedefs for "Int", "Bool", etc. because "Types must use Pascal case, period". this is quite weird to see proper naming for user types and "int" nearby, and why people still tolerate it is beyond me, as it is a one minute "typedef" fix.

It is a bad thing. Everyone needs to now know if they’re reading from your code base or somewhere else and gotta re-train their eyes.

Not that it’s strictly harmful, that’s reserved for when you’re overriding existing symbol (well, someone managed a dishonorable mention in ioccc with that iirc). Still, it’s a totally unnecessary burden.

A lot of things are, doesn't mean it has to be a good idea.

while true {
  // Intentionally left blank

Is some good candidate. Again, what you did is not exactly bad, just unnecessary. Those who’ll pass through your code will need to adapt. And if you’re going to post on any forum, you’ll likely need to port it back to “normal Swift”.

1 Like

I’m still struggle to find the usage of 'like' in your example. If you’re replacing printable text with another printable text, you might as well just use one of them.

1 Like
Terms of Service

Privacy Policy

Cookie Policy