On 2018-02-12 23:35, Walter Bright wrote:
The last dstep commit was November 2017.
Yes? I've been working on a separate branch lately
I take it dstep spawns the clang compiler?
No, it uses libclang, i.e. using the Clang compiler as a library.
--
/Jacob Carlborg
On Tuesday, 13 February 2018 at 04:44:27 UTC, timotheecour wrote:
Try to comment that with `/* */`:
```
void drawCircle(int angle /* in degrees */);
```
When you want to disable whole declaration, version(none) works
just fine.
On Tuesday, 13 February 2018 at 04:16:22 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 07:11 AM, Kagamin wrote:
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 05:31 AM, Kagamin wrote:
version(none)q{ FOO }; is likely to work for most stuff to
On 02/09/2018 07:11 AM, Kagamin wrote:
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky (Abscissa)
wrote:
On 02/09/2018 05:31 AM, Kagamin wrote:
version(none)q{ FOO }; is likely to work for most stuff too.
/+ +/ is likely to work for most stuff, too.
So do /* */
Seriously, are
On 2/12/2018 12:23 PM, Jacob Carlborg wrote:
Here you go [1]. It's a bit outdated now, from 2013, but it worked back then.
The last dstep commit was November 2017.
[1]
https://github.com/jacob-carlborg/dmd/commit/2837d340c065cc2bf3f0a83cb96c4d9f22fb3a30
I take it dstep spawns the clang c
On Monday, 12 February 2018 at 22:35:23 UTC, Walter Bright wrote:
I take it dstep spawns the clang compiler?
It embeds the Clang frontend, which is designed to be usable as a
library.
— David
On 2/12/2018 8:25 AM, Patrick Schluter wrote:
C is currently at [C11].
[C11]: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
Yes, you're right. I haven't paid any attention to C11 :/
The array bounds checking interface,
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.h
On 2018-02-12 02:27, Walter Bright wrote:
Know what is a heavyweight problem worth our while? Having dmd be able
to directly read C .h files, so the poor user does not have to manually
translate them.
We've already got a huge chunk of that problem solved. The Digital Mars
C/C++ front end is now
On Monday, 12 February 2018 at 03:17:20 UTC, Walter Bright wrote:
On 2/11/2018 6:26 PM, Elie Morisse wrote:
Wow, you converted DMC++'s front-end to D?
Yes, it's just frustrating for me to work on C++ code anymore.
:-)
To chime in on that, Calypso i.e the LDC+Clang equivalent of
what you de
On 2/11/2018 8:59 PM, Nick Sabalausky (Abscissa) wrote:
Though I do realize that's not likely to happen. It's not as if I'm saying "hey,
go do this". All I'm really saying is "I like this idea, I'm in favor of it, and
it's worth being open to." Not much more than that.
> "That's a reasonable p
On 02/11/2018 08:27 PM, Walter Bright wrote:
On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the
nice things in D, like separators for numeric literals: Because
they're not strictly necessary. But if D had never been willing
On 2/11/2018 6:26 PM, Elie Morisse wrote:
Wow, you converted DMC++'s front-end to D?
Yes, it's just frustrating for me to work on C++ code anymore. :-)
To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described
isn't dead (it just revived a few weeks ago from a long slumb
On 2/11/2018 5:43 PM, timotheecour wrote:
It doesn't leave anything in Ddoc either, so that's not a viable workaround if
that comment is intended to be a DDoc.
You're right that this will never be intrepreted as a Ddoc comment. But I infer
that this resolves the non-Ddoc case?
As for Ddoc co
On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
Know what is a heavyweight problem worth our while? Having dmd
be able to directly read C .h files, so the poor user does not
have to manually translate them.
We've alread
On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
Know what is a heavyweight problem worth our while? Having dmd
be able to directly read C .h files, so the poor user does not
have to manually translate them.
read directly C++ header files instead of C .h files is what we
shou
On Monday, 12 February 2018 at 01:39:31 UTC, Walter Bright wrote:
Easy:
mixin template comment(string s) { }
mixin comment!q"EOS
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like
https://gcc.gnu.org/
On 2/8/2018 7:06 PM, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/
Easy:
mixin template comment(string s) { }
mixin comment!q"E
On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the nice things
in D, like separators for numeric literals: Because they're not strictly
necessary. But if D had never been willing to improve the state of the art by
not being
On 02/10/2018 06:03 PM, Walter Bright wrote:
There isn't any commenting scheme that won't trip you up with certain
characters
That's exactly the whole point of heredocs ever existing in the first
place, its exactly the problem they're created for.
in the comments. I don't see a compelling
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
same exact idea as motivation for delimited strings
(https://dlang.org/spec/lex.html#delimited_strings)
```
auto heredoc = q"EOS
This is a multi-line
heredoc string
EOS"
;
/"EOC
This is a multi-line
heredoc comment allowing
/+ d
On 02/11/2018 09:32 AM, Vladimir Panteleev wrote:
This syntax is syntactically ambiguous.
[...]
assert(StringNumber("4")/"2" == "2"); // Conflict!
// Division by string, or nested comment?
Strictly, it's not worse than `/*`, is it?
assert(4/*(new int(2)) == 2);
//
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/
This syntax is syntactically ambiguous.
stru
On Sunday, 11 February 2018 at 01:01:21 UTC, Jonathan M Davis
wrote:
You could also always just declare a DDOC macro.
Just put
Macros:
PLUS=+
in the ddoc comment and then use $(PLUS) instead of +. It's
more verbose that way given that PLUS isn't one of the standard
ddoc macros, but it's
On 2/10/2018 7:27 PM, Jonathan M Davis wrote:
And it's already kind of silly
that we have as many comment types as we do.
Even more comment types implies we don't know what we're doing :-(
On Saturday, February 10, 2018 18:53:03 Walter Bright via Digitalmars-d
wrote:
> On 2/10/2018 6:28 PM, Timothee Cour wrote:
> > all these workarounds are rather ugly; the proposed syntax works all
> > the time (user can just pick a EOC token not in comment) and is analog
> > to existing D heredoc
On 2/10/2018 6:28 PM, Timothee Cour wrote:
all these workarounds are rather ugly; the proposed syntax works all
the time (user can just pick a EOC token not in comment) and is analog
to existing D heredoc strings, so nothing surprising there.
Would PR's be accepted?
You'll need to make a strong
all these workarounds are rather ugly; the proposed syntax works all
the time (user can just pick a EOC token not in comment) and is analog
to existing D heredoc strings, so nothing surprising there.
Would PR's be accepted?
On Sat, Feb 10, 2018 at 5:01 PM, Jonathan M Davis via Digitalmars-d
wrot
On Saturday, February 10, 2018 15:03:08 Walter Bright via Digitalmars-d
wrote:
> On 2/8/2018 7:06 PM, Timothee Cour wrote:
> > /"EOC
> > This is a multi-line
> > heredoc comment allowing
> > /+ documented unittests containing nesting comments +/
> > and weird urls like https://gcc.gnu.org/onlinedo
On 2/8/2018 7:06 PM, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/
There isn't any commenting scheme that won't trip you up with certain
On Saturday, 10 February 2018 at 07:57:12 UTC, Vladimir Panteleev
wrote:
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
and weird urls like
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
Workaround: percent-encoding.
https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/faq.html w
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
and weird urls like
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
Workaround: percent-encoding.
https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/faq.html works too.
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky
(Abscissa) wrote:
/**
Be sure to check the various files at extras/foo*/package.d
and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/
Unlike the "disabling code that contains the
end-of-disabled-code token" stuff, THIS exam
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 05:31 AM, Kagamin wrote:
On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky
(Abscissa) wrote:
Huh? So are you *pro-* or *anti-* heredoc?
I personally prefer python's triple quoted strings. Elega
On Friday, 9 February 2018 at 09:48:14 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 04:09 AM, Kagamin wrote:
On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour
wrote:
* `/* */` should never be used
Not a single reason for that
Except of course for the ones that have been pointed
On 02/09/2018 05:31 AM, Kagamin wrote:
On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky (Abscissa)
wrote:
Huh? So are you *pro-* or *anti-* heredoc?
I personally prefer python's triple quoted strings. Elegant, simple and
enough for most stuff. That example only shows what D has.
ver
On 02/09/2018 04:48 AM, Kagamin wrote:
On Friday, 9 February 2018 at 09:34:01 UTC, Nick Sabalausky (Abscissa)
wrote:
Comments don't respect even lexical structure of commented code that
you expect, version(none) does.
Uhh, you do know that IS nesting, right?
It's not a comment though, it dis
On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky
(Abscissa) wrote:
Huh? So are you *pro-* or *anti-* heredoc?
I personally prefer python's triple quoted strings. Elegant,
simple and enough for most stuff. That example only shows what D
has.
version(none)q{ FOO }; is likely to work f
On Friday, February 09, 2018 08:42:08 Kagamin via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 07:04:26 UTC, Nick Sabalausky
>
> (Abscissa) wrote:
> > (If I were in change of the world, /** and /* both would be
> > compiler errors, banned from all commits, and non-nesting block
> > comments
On Friday, 9 February 2018 at 09:34:01 UTC, Nick Sabalausky
(Abscissa) wrote:
Don't see how that's remotely as common as "*/" in a
C-style-comments codebase or commenting out something at the
sub-statement level, like a function argument, type modifier or
sub-expression, but hey, I guess if you
On 02/09/2018 04:09 AM, Kagamin wrote:
On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour wrote:
* `/* */` should never be used
Not a single reason for that
Except of course for the ones that have been pointed out. And for the
reasons you yourself brought up in favor of version(none). N
On 02/09/2018 04:23 AM, Kagamin wrote:
On Friday, 9 February 2018 at 08:57:49 UTC, Timothee Cour wrote:
version(none) { FOO } doesn't work if FOO doesn't parse.
version(none)q"EOS
FOO
EOS";
Huh? So are you *pro-* or *anti-* heredoc?
But ok, that works, unless the code contains `EOS"`. Be
On 02/09/2018 03:52 AM, Kagamin wrote:
On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky (Abscissa)
wrote:
On 02/09/2018 03:42 AM, Kagamin wrote:
Nested comments are superficial though,
Not if you've ever commented out a block of code.
Comment this:
'kay:
// string sedArg="s/
On Friday, 9 February 2018 at 08:57:49 UTC, Timothee Cour wrote:
version(none) { FOO } doesn't work if FOO doesn't parse.
version(none)q"EOS
FOO
EOS";
On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour wrote:
* `/* */` should never be used
Not a single reason for that
* properly nested `/+ +/` indeed don't cause issues
Disproved two times in this thread. Anyway nothing properly done
causes issues.
* unrestricted code (eg foreign co
version(none) { FOO } doesn't work if FOO doesn't parse.
Again, what I proposed is the only 100% reliable way to comment out something
On Fri, Feb 9, 2018 at 12:52 AM, Kagamin via Digitalmars-d
wrote:
> On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky (Abscissa)
> wrote:
>>
>> On 02/0
On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 03:42 AM, Kagamin wrote:
Nested comments are superficial though,
Not if you've ever commented out a block of code.
Comment this:
string sedArg="s/ +/ /";
Comments don't respect even lexical structur
summary:
* `/* */` should never be used
* properly nested `/+ +/` indeed don't cause issues
* urls cause issues and I've ran into this issue multiple times
* unrestricted code (eg foreign code or unfinished D code commented
out) also cause issues
* hreredoc comments fixes these issues when neeeddd
On 02/09/2018 03:37 AM, Kagamin wrote:
/**
This is a multi-line
heredoc comment allowing
// documented unittests containing nesting comments
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/
/**
This is a multi-line comment.
Be sure to check the various files at extras/f
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
Are you sure documented unittests work that way?
https://run.dlang.io/is/grNpKK
On Friday, 9 February 2018 at 07:04:26 UTC, Nick Sabalausky
(Abscissa) wrote:
(If I were in change of the world, /** and /* both would be
compiler errors, banned from all commits, and non-nesting block
comments of all types would be prohibited from all langauges
upon pain of...well, pain. They
On 02/09/2018 03:42 AM, Kagamin wrote:
Nested comments are superficial though,
Not if you've ever commented out a block of code.
/**
This is a multi-line
heredoc comment allowing
// documented unittests containing nesting comments
and weird urls like
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/
On 02/08/2018 10:06 PM, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
That shouldn't be an issue as long as you're using /++ doc comments and
not /** ones. If it IS a problem, I'd regard it as a bug.
(If I wer
NOTE:
the analog of documenting comments (/++ ...+/ and /** */) could be:
/""EOC
multiline comment
EOC"/
(ie allow both `/""` and `/"` before reading in the heredoc token)
On Thu, Feb 8, 2018 at 7:06 PM, Timothee Cour wrote:
> same exact idea as motivation for delimited strings
> (https://dlan
54 matches
Mail list logo
