In the spirit of being more transparent about feature propositions, and because Araq asked me to, here is a thread discussing my feature request: a new comment syntax.
Bigger description in this Github issue: https://github.com/Araq/Nimrod/issues/1535.
Feel to discuss it here, on IRC, or on Github.
Also, let's be democratic: so in your reply tell us if you think this is a good idea or not with a unambiguous Yes or No.
This is a off-topic but it would be very handy, eventually, to be able to extract information from inside multiline comments during compilation and do something with it. What I have in mind specifically is to be able to extract code snippets and check them syntactically and maybe even execute them and write the result back into the source code.
And as the syntax I'd prefer /* ... */, since I am used to it from C and would avoid # since it associates with C preprocessor. Multiline comments should nest, though.
You've got to be kidding me. /* */ is ugly and was a bad idea for C too:
int* p=&a;
printf("%d\n", q/*p);
template `*`(a): expr = a*4
var x = 9
echo(*x)
Likewise /* can be defined as an operator. :P Trust me, /* */ is a bad choice.
Well, then it seems you're right :) and multi-line comment's first character should be #, as it cannot be used with operators, etc anyway.
Didn't get about # [ (with and without space).
proc func1(v1: int, v2:string = "hey", # [ v2 is a string ] # v3:int=5) =I assume the above would work if implemented?
Yes #[ ... ]# ### ... ###
But I don't like:
{- ... -}(* ... *)(°,,,°)(^._.^)(>_<)(¬_¬)(╯°□°)╯(^•ﻌ•^)(•̀ɷ•́)(ಠ_ಠ)
If we introduce them they will most likely be #[ comment here ]#.
@GravityWell: Yes.
@erikenglund: you are wrong. some people use not so smart text editors and having every line prefixed with # is bummer.
I also think #[ ... ]# makes most sense. @dom96 mentioned ##[ ... ]## for doc comments. Im not sure why there would be dedicated syntax for that? Take python for instance - they get away with docstrings in ordinary multiline comments. Why? Simply because docstrings appear in special place. This prevents people from scattering docs all over the inapprorpiate places and keeps it simple because there is one thing less to learn/know/type.
There is absolutely no point..
You could argue that multilines are somewhat redundant in modern IDE's, although you could also say that all case statements could be replaced with if/elif, or other constructs. The proposed syntax does add the capability to insert comments within a line (not sure what the term for that is), which is currently not possible in Nim (or Python).
It comes down to a design choice, and I'm quite satisfied with Andreas's design choices, so I'll be interested to see if he incorporates this.