Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
On 6/8/16 2:45 PM, Sönke Ludwig wrote:
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.
"It's still possible to put something else in front of it"
I didn't get this. How is /+ different from /*? I thought the only issue
was the nesting.
I mean together with the restriction that it has to be the first /+ +/
comment, it is possible to put // and /* style comments in front of it
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
Thanks. Perhaps more debate is fruitless until someone steps up with an
Rory has started an implementation: https://github.com/dlang/dub/pull/872
But this has brought up another issue. The idea was to allow the recipe
comment to be anywhere in the file and be of any comment style. However,
that basically almost requires a full D lexer (at least string literals
need to be parsed in addition to the comment styles).
I'm reluctant to include this in the current state, because the results
for a program such as the following will be very confusing:
bool foo(string str)
/* dub.sdl: ... */
The string literal will be recognized as the start of a comment and thus
the real comment below will not be recognized. So I think we should
either have a generic and correct version, or one that is restricted
similar to the current one to sidestep such issues.
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
How would this be a breaking change? It seems an additive feature, and
I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now
not considered as a recipe comment candidate. Depending on its contents,
the behavior could change once /* */ is also recognized. However, that
case would be easily detectable and a warning could be emitted instead,
while falling back to the old behavior. So it's not really an issue