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

people are too obsessed with operators. there's nothing wrong with writing delta(...) nabla(...)

1 Like

Except for readability, which is also the point of this thread, nothing indeed, but we'd still take advantage of it if available.

Yeah it probably woulnd't. I'm not a fan of ! myself, for either of its uses in Swift, because it's way too small relative to the massive impact it has (literally reversing everything else on a line in a boolean expression, or crashing if a force unwrap fails).

I'd really prefer if force unwrapping was spelt .forcefullyUnwrapOrThrow(error:) or something else along those lines. Very long, very salty, and very clear.

I also like the not spelling in Python.

But yes, you should be using a linter, it's incredibly necessary.

2 Likes

That’d be Optional.unsafelyUnwrapped

2 Likes

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 }
2 Likes

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

6 Likes

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
Terms of Service

Privacy Policy

Cookie Policy