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

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

"Everyone"? you are thousand miles away and this is a closed source. the close circle of fellow developers in question were able to adapt to this convention (that "let" means "const auto" and that "Int" is a proper name for "int") in a matter of minutes. and anyways, no worries, i am not forcing anyone outside the company to do the same :slight_smile:

i am not. it's a pure additive change

It is true I don’t see your code, and it’s just a small hurdle (for now) to cross into/out of this code base. Still, as said, it’s totally unnecessary.

I know. Maybe my 2AM English got a little weak and that’s not conveyed through. :thinking: Guess it’s time to call it a day. :hugs:

the potential benefits are big IMHO:

  1. the language becomes simpler (especially if your further restrict identifiers to be ASCII only. i'd get rid of :dog::cow: identifiers any day - it's just silly).

  2. no questions like this one:

neither on the usage side nor on the swift language design side.

  1. you will be able to use for operators a sequence of unicode characters (for the visualisation) that previously were disallowed.

  2. if you do not like to see those emojis, you just turn the relevant IDE setting off and enjoy the pure ASCII form of the operators: "i like this" (still enfolded when in IDE)

  3. there will always be a "canonical" ascii name for the operator. good for searching, googling, etc.

when i have to enbold something here i enclose it with "**" symbols, and on the read side you enjoy the bold version. this is very similar to the proposed embedding operator name in quotes...

no, it must be my 5AM english reading ability :slight_smile:

The page I linked to has the following advice:

"Don't change syntax via macro substitution. It makes the program unintelligible to all but the perpetrator."

Jeremy

3 Likes

do not take that too religiously. there are legitimate uses for macros and the particular example of "let" vs "const auto" is a change that makes real difference: chances your fellow C++ developer uses the latter is slim for the very reason of the ugliness of "const auto". for "Int" i do not even use a macro, it's a typedef.

from that same link:

obvious if you need that to be interop to swift you'd use a different naming:

enum PinStateType { // DEFINE_ENUM here would be actually used
PinStateTypeOff,
PinStateTypeOn
};

obvious if your team adopted the camel case for identifiers you won't do that. the local rules of your team have precedence over such advices. in my team the above would be:

Int handleError(Int errorNumber) {
let error = osErr();
let timeOfError = ...;
let errorProcessor = ...;
}

That looks like an interesting design. There are some rough edge, but is interesting nonetheless.

Unicode has a lot more than emoji, but ok. That’s what it’s know for these days anyway.

2 Likes