what is SwiftLint and is it really necessary? 
if swift was invented today would it use the same symbol for unsafe operations and logical operations? i very much doubt so. when i see ! this screams "unsafe" to me, like a high voltage sticker. there is nothing unsafe in logical not and comparison operation, so they shall not have this dangerous sticker.
I don't think force unwrap ! is as big of a problem.
Usually it happens when the return type shouldn't be optional but is (aka ObjC or simply some porting) and it lies with the faulty API design. Otherwise there's some handling of optional that shouldn't be ignored.
Personally, I'm against adding new operators that does exactly the same thing as an existing one for the sake of correctness.
It quickly divide your code from the rest of the community/language.
there was no euro sign on the keyboards either... keyboards can evolve. until then - there are probably many different ways how to enter those symbols.
even if swift is "Objective-C minus C"
This discussion reminds me of when (a small number of) people thought it would be cool to use the C preprocessor to convert C into a language they were more familiar with (typically BASIC or Pascal).
https://users.ece.cmu.edu/~eno/coding/CCodingStandard.html#macros
Jeremy
please note that there were "and" / "or" keywords in C/C++. don't remember exactly since what version, probably from the very beginning.
IMO there's merit with the current design
agreed
i wonder if anyone seriously using non ascii custom operators or non-ascii identifiers... if they were ditched from the language it wouldn't cause too much harm (IMHO).
and if it wasn't possible to create new custom operators (like the mentioned <>) the language would be simpler and we'd not have this discussion. win-win
TensorFlow community for one, it uses ∂, ∆ and ∇ quite extensively. Not that I myself use them, though.
We'd have a different discussion about how there aren't nearly enough operators to work with. Lest we forget C++ << 
.
people are too obsessed with operators. there's nothing wrong with writing delta(...) nabla(...)
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.
That’d be Optional.unsafelyUnwrapped
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.
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.