RFC: Custom operators

[Qix-]

Swift has a very interesting semantic for creating custom operators. I like the idea, though I am a skeptical C++ adept and have seen a few horrific examples of it being done. However, I'm not opposed to the idea completely and think it could have some amazing results.

One of the constraints in place would be that custom operators can only be defined where the associative type itself is defined. For builtins or the standard library, this constraint can be turned off (as it can be with regular code via compiler details).

This would allow us to write a lot of the language in Arua directly, and open the door for a feature I mentioned once but originally discarded, complex/advanced math operators (#16).

[corbin-r]

I think (as you said) custom operators but in a limited sense would be nice, being able to write arua in arua would help with reducing overhead.

[Qix-]

being able to write arua in arua would help with reducing overhead

As well as reducing the number of things needed in the bootstrap compiler and the self-hosted compiler. :+1: I like that.

[corbin-r]

Exactly. Because the thing with most languages, is they're written in itself.. Then some sort of C/C++ overhead for the compiler and the bootstraper. Which just takes up compiler time and runtime speed.

[Qix-]

@Polygn So do you think the constraint of having operators only being definable in the module that defines the associative type reasonable? It'd prevent willy-nilly operator overloading but still allow certain classes to work correctly, for example, but won't allow you to overload i32 + i32.

[corbin-r]

@Qix- Yes, I think that is perfectly reasonable. Due to the fact that if you allowed having these custom operators outside the module that defines the associative type, I would assume you'd have problems with the compiler getting it to actually link them (cause it's thinking "well where do I look for this operator?!").

I mean I'm all for operator overloading, but so often (as seen in C++) it can get you in trouble.. Especially if you have someone that doesn't know how operator overloading works (trust me I've done it before I know fully haha).

[Qix-]

Very true, didn't think about that. Looking up operators for associative types would be impossible without them loaded, and having to have the entire codebase indexed for them to find operators would kill incremental compilation.

[corbin-r]

@Qix- exactly! Without some form of pre-indexing or pre-compile the custom operators wouldn't even be indexed by the compiler.

EDIT Thus it would have to go through and index all the symbols then go through and compile the whole thing.

[Qix-]

Yeah exactly. So this works on a few fronts.