On 6/8/16 8:21 AM, Jacob Carlborg wrote:
On 2016-06-08 11:15, Sönke Ludwig wrote:
I generally really do appreciate your critique, but without backing
reasons it doesn't really have a constructive effect.
Two good properties about restricting to /+ +/ is that it's still
possible to put something else in front of it, and that it stands out
from the usual /* */ comments. Sure arguments can be made for supporting
all comment types, but it shouldn't be forgotten that in the end this is
a question of absolutely minimal impact.
Just to be clear: If anyone has a good argument for supporting more/all
comment types and there are no equally good arguments against it, please
go ahead and implement it and it will be included. Let's just make this
a quick decision, because changing it later on will mean breakage no
matter how it's done.
It's just that since the language support other styles of comments one
could think that all comments are supported and it will cause confusion
if only one style is supported. Otherwise it might be better to use a
UDA, if possible.
If one reads the documentation and copy pastes and example the user will
most likely get it right. But if you have a conversation saying
something like "it's possible to put the content of dub.json inline in
the source code, just put it in a comment" then someone will for sure
try using a comment style that is not supported.
The documentation needs to be very clear that only one type comments are
supported, if that's the conclusion.
I agree with Jacob. A comment is a comment. There is no reason one needs
to use specifically /+. In fact the only reason for the existence of /+
is to allow nesting of comments -- which doesn't apply here. I'd say you
should support // comments as well.
There's another aspect here, in that most people (even core D
developers) use the /* comment style */. So someone seeing the /+
comment might think this is a specialized dub thing.
I will finally say this: if such an implementation update existed, what
would be the reason NOT to pull it? That is, I think literally the only
reason not to support /* for this purpose is that nobody has done the
work. If you can give no better reason, it should take away any barriers
for anyone wishing to create this improvement.
-Steve
