3 ms·

I think the danger of abuse is stronger when you overload existing operators than when you make up new ones. The latter can't fool you on its semantic and beha

by micampe 12y ago

I think the danger of abuse is stronger when you overload existing operators than when you make up new ones. The latter can't fool you on its semantic and behavior.

Someone 12y ago
I bet we will see some interesting examples of fooling in obfuscated Swift contests. For example one can define operators called <>, =<, =>, and != You can do interesting stuff with pre- and suffix operators, too. For example, the XML comments  could be a prefix- and suffix operator pair. Also, you could define operators that look conspicuously like comments, at least to some of your readers. [disclaimer: I don't have access to the code; I just read the documentation. That documentation seems to imply that // starts a comment _and_ can be used to implement a custom operator. Even if that isn't possible (fairly likely, I would say, you can still try using --- or /// as your operator]
- micampe 12y ago
  Ok, let me replace my “can’t” with “is a lot less likely to”. I checked: neither // nor /// can be used as operators (syntax error: they both just start a comment). All your other examples work, but I would say those mean the author is intentionally trying to trick me. Or he’s writing a clever DSL, but that line is very fine and treacherous.
  - Someone 12y ago
    Thanks for the checking. And I agree: that line is thin. Some other food for thought: a = b-- // !z x = y--// ! z The first does a = b - 1 and has a comment, the second calls suffix --// on y, then infix ! On the result and z. A variation: x+ - 3 x + -3 I think it is fair to say that Swift introduces a new variant of whitespace sensitivity. Also, the docs do not seem to discuss line breaks inside statements. If they are legal, you can do: x+ -3 vs x+{space} - 3 I think I would find it fun to stress test this language.

by micampe 12y ago

I think the danger of abuse is stronger when you overload existing operators than when you make up new ones. The latter can't fool you on its semantic and behavior.

Someone 12y ago

I bet we will see some interesting examples of fooling in obfuscated Swift contests. For example one can define operators called <>, =<, =>, and != You can do interesting stuff with pre- and suffix operators, too. For example, the XML comments  could be a prefix- and suffix operator pair. Also, you could define operators that look conspicuously like comments, at least to some of your readers. [disclaimer: I don't have access to the code; I just read the documentation. That documentation seems to imply that // starts a comment _and_ can be used to implement a custom operator. Even if that isn't possible (fairly likely, I would say, you can still try using --- or /// as your operator]

micampe 12y ago
Ok, let me replace my “can’t” with “is a lot less likely to”. I checked: neither // nor /// can be used as operators (syntax error: they both just start a comment). All your other examples work, but I would say those mean the author is intentionally trying to trick me. Or he’s writing a clever DSL, but that line is very fine and treacherous.
- Someone 12y ago
  Thanks for the checking. And I agree: that line is thin. Some other food for thought: a = b-- // !z x = y--// ! z The first does a = b - 1 and has a comment, the second calls suffix --// on y, then infix ! On the result and z. A variation: x+ - 3 x + -3 I think it is fair to say that Swift introduces a new variant of whitespace sensitivity. Also, the docs do not seem to discuss line breaks inside statements. If they are legal, you can do: x+ -3 vs x+{space} - 3 I think I would find it fun to stress test this language.