Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:
I agree with Jacob. A comment is a comment.
Well, there are normal comments, doc comments and now DUB recipe comments. But at least if doc comments serve as an analogy, those are possible with all three comment styles, so that could be taken as a consistency argument.
> 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.
SDLang supports C and C++ style comments as well, so could in fact apply here. But probably you'd usually use // style comments in that case.
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.
Would there be any harm? Looking it up in either DUB's or DMD's documentation would clarify that.
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.
Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case.
Okay, so at least 3 people favor supporting other comment styles, while I'm not convinced that supporting all comment styles is necessarily better, I wouldn't mind pulling an update. The relevant code section is here: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
It would probably make sense to unify the comment matcher with the one here, which currently doesn't support /+ +/ comments: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/internal/utils.d#L430
1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to avoid stretching the release schedule (it's technically a breaking change!).