Am 07.06.2016 um 15:45 schrieb Jacob Carlborg:
> On 2016-06-07 13:22, Sönke Ludwig wrote:
>
>> Oh, I typed that by accident, should be /+ dub.sdl: ... +/
>> BTW, /+ dub.json: ... +/ is also possible, of course.
>
> Does it work with all kind of comments D supports?
>

No, it has to be the "+" variant (the first /+ +/ comment is evaluated).

On 2016-06-07 20:42, Sönke Ludwig wrote:

> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).

That's unfortunate.

-- 
/Jacob Carlborg

Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
> On 2016-06-07 20:42, Sönke Ludwig wrote:
>
>> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
>
> That's unfortunate.

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.

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.

-- 
/Jacob Carlborg

On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:

> 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.

That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all.

We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line:

#!/usr/bin/env dub
// dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"

Am 08.06.2016 um 15:27 schrieb burjui:
> On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:
>
>> 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.
>
> That reason alone is enough. Restricting DUB special comments to only
> /++/ will put users off, because now they know that there's a cool
> feature in DUB, but it only works with certain types of comments, that
> nobody wants to remember (why should they?), so they will decide that
> this feature is either broken or unfinished and will hardly use it at all.
>
> We could make users' lives easier, if we allowed them to just specify
> the dependencies in Gradle style on a single line:
>
> #!/usr/bin/env dub
> // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
>

But the user *will* remember the filename + colon requirement? Or will remember yet another format to specify dependencies? What if something else, such as compiler flags or link libraries need to be specified?

I'll stay out of this discussion until there is a conclusion now.

On Wednesday, 8 June 2016 at 13:27:31 UTC, burjui wrote:
> That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all.
>
> We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line:
>
> #!/usr/bin/env dub
> // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"

I don't understand this argument. There are two options: /++/ and /**/. If a user can't remember which one it is, it's a matter of a few seconds to find out. With all the things we need to remember about a language when programming, I hardly think something of this nature is going to put anyone off. And if they *are* put off by it, they've got bigger issues than trying to remember which comment style to use.

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

On Wednesday, 8 June 2016 at 09:15:09 UTC, Sönke Ludwig wrote:
> 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.

It stands out because we don't have a recognizable convention for such... processing instructions, every tool uses its own. BTW do people find nested comments particularly useful?

On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote:
> BTW do people find nested comments particularly useful?

Yes for:

A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */)

B) code examples inside comments