www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - -preview switches

reply Steven Schveighoffer <schveiguy gmail.com> writes:
dmd '-preview=?'

Upcoming language changes listed by -preview=name:
   =all              list information on all upcoming language changes
   =dip25            implement 
https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md (Sealed 
references)
   =dip1000          implement 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md (Scoped 
Pointers)
   =dip1008          implement 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md ( nogc 
Throwable)
   =dip1021          implement 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md 
(Mutable function arguments)
   =fieldwise        use fieldwise comparisons for struct equality
   =markdown         enable Markdown replacements in Ddoc
   =fixAliasThis     when a symbol is resolved, check alias this scope 
before going to upper scopes
   =intpromote       fix integral promotions for unary + - ~ operators
   =dtorfields       destruct fields of partially constructed objects
   =rvaluerefparam   enable rvalue arguments to ref parameters
   =nosharedaccess   disable access to shared memory objects


Any idea on when these will become permanent or be removed? We are 
collecting quite a few of these. Which means, we are currently shipping 
2^11 different compilers simultaneously (I know there's really less 
since some of them activate the others).

If nobody knows about these switches, then they don't get used, you 
can't build libraries with them (including phobos/druntime), and you 
won't use them. Which means existing code is not going to be prepared 
when we turn these on.

Alternatively, we should examine other ways to progress these changes 
(or cancel them). I think the only preview switches I've ever used are 
dip1000 and dip25. I forgot about all the others.

One I can see right now that is probably not controversial is the 
markdown one.

This is another reason to have a distinctive versioning system, we could 
target specific versions for permanent inclusion of these switch 
features, and people can work on making sure things work with those 
switches. By just tossing switches out there and forgetting about them, 
they don't get the attention they need.

-Steve
Apr 01
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 1 April 2020 at 14:15:36 UTC, Steven Schveighoffer 
wrote:
 dmd '-preview=?'

 Upcoming language changes listed by -preview=name:
   =all              list information on all upcoming language 
 changes
   =dip25            implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md 
 (Sealed references)
   =dip1000          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md 
 (Scoped Pointers)
   =dip1008          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md 
 ( nogc Throwable)
   =dip1021          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md (Mutable
function arguments)
   =fieldwise        use fieldwise comparisons for struct 
 equality
   =markdown         enable Markdown replacements in Ddoc
   =fixAliasThis     when a symbol is resolved, check alias this 
 scope before going to upper scopes
   =intpromote       fix integral promotions for unary + - ~ 
 operators
   =dtorfields       destruct fields of partially constructed 
 objects
   =rvaluerefparam   enable rvalue arguments to ref parameters
   =nosharedaccess   disable access to shared memory objects

 [...]
Walter and I discussed this last week. I think the right way to nudge D programmers to transition to where we can turn -preview into -revert is to issue deprecation messages for a while. Nothing like a noisy build to get people to file issues on github (or even better, PRs) to get this fixed. I expect the annoying messages to happen soon. Then we have to decide on how long of a period is appropriate to start break builds.
Apr 01
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 1 April 2020 at 14:26:15 UTC, Atila Neves wrote:

 Walter and I discussed this last week.

 I think the right way to nudge D programmers to transition to 
 where we can turn -preview into -revert is to issue deprecation 
 messages for a while. Nothing like a noisy build to get people 
 to file issues on github (or even better, PRs) to get this 
 fixed.
While I understand this would be more work I still believe supporting both is going to be critical. It is one thing to update your code to breaking changes, it is completely different to do it for all your dependencies. I'm not saying to support all versions indefinitely, but having clear breaking change releases where a dub package can build with D 3.x and build 2.x libraries will make for easier transitions. The 2.x build can have all the depreciations that are breaking in 3.x. Realistically, the 2.x would probably just be 3.x using --revert.
Apr 01
prev sibling next sibling parent reply Johan <j j.nl> writes:
On Wednesday, 1 April 2020 at 14:26:15 UTC, Atila Neves wrote:
 I think the right way to nudge D programmers to transition to 
 where we can turn -preview into -revert is to issue deprecation 
 messages for a while. Nothing like a noisy build to get people 
 to file issues on github (or even better, PRs) to get this 
 fixed.
Please note that deprecation messages are effectively errors in a build environment with -de (i.e. Weka). In that case the only workable compilation is to use the new way (i.e. with preview switch). Especially due to deprecation/error messages in speculative code, this can be annoying to deal with. What is nice about _not_ showing deprecation messages and instead having only -preview, is that it is easier to switch to a new compiler (which always creates a ton of work already). And then slowly one can enable the preview options to get ready for the future. I do think that putting a date on certain things will help create some urgency to start future proofing code. -Johan
Apr 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 3:01 PM, Johan wrote:
 On Wednesday, 1 April 2020 at 14:26:15 UTC, Atila Neves wrote:
 I think the right way to nudge D programmers to transition to where we 
 can turn -preview into -revert is to issue deprecation messages for a 
 while. Nothing like a noisy build to get people to file issues on 
 github (or even better, PRs) to get this fixed.
Please note that deprecation messages are effectively errors in a build environment with -de (i.e. Weka). In that case the only workable compilation is to use the new way (i.e. with preview switch). Especially due to deprecation/error messages in speculative code, this can be annoying to deal with. What is nice about _not_ showing deprecation messages and instead having only -preview, is that it is easier to switch to a new compiler (which always creates a ton of work already). And then slowly one can enable the preview options to get ready for the future. I do think that putting a date on certain things will help create some urgency to start future proofing code.
I think compiler deprecation messages can be designated as not becoming errors for -de. For example, I'm pretty sure the import changes that were done not too long ago had deprecation messages that never resulted in errors. -Steve
Apr 01
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-04-01 21:15, Steven Schveighoffer wrote:

 I think compiler deprecation messages can be designated as not becoming 
 errors for -de.
Not sure I follow. The whole point of the `-de` flag is to turn deprecation messages into errors. By default, they're not errors. -- /Jacob Carlborg
Apr 01
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, April 2, 2020 12:30:49 AM MDT Jacob Carlborg via Digitalmars-d 
wrote:
 On 2020-04-01 21:15, Steven Schveighoffer wrote:
 I think compiler deprecation messages can be designated as not becoming
 errors for -de.
Not sure I follow. The whole point of the `-de` flag is to turn deprecation messages into errors. By default, they're not errors.
For compiler changes which have involved deprecated features or behavior, for better or worse, the messages haven't necessarily been affected by the compiler flags related to deprecation, whereas because deprecations in druntime or Phobos have actually used the deprecated keyword, they've been affected by the deprecation flags. - Jonathan M Davis
Apr 02
prev sibling parent Arine <arine123445128843 gmail.com> writes:
On Wednesday, 1 April 2020 at 14:26:15 UTC, Atila Neves wrote:
 Walter and I discussed this last week.

 I think the right way to nudge D programmers to transition to 
 where we can turn -preview into -revert is to issue deprecation 
 messages for a while. Nothing like a noisy build to get people 
 to file issues on github (or even better, PRs) to get this 
 fixed.

 I expect the annoying messages to happen soon. Then we have to 
 decide on how long of a period is appropriate to start break 
 builds.
So basically warning messages? Does that mean this issue will finally be fixed? https://issues.dlang.org/show_bug.cgi?id=259 #issue259
Apr 02
prev sibling next sibling parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 4/1/20 7:15 AM, Steven Schveighoffer wrote:
 One I can see right now that is probably not controversial is the 
 markdown one.
That switch is already enabled when building DMD and Phobos docs--enabling it required escaping a few places where existing docs accidentally had markdown syntax. However I didn't enable it for druntime docs because they won't build on my Mac*, so I can't easily compare output with the switch on and off. * src/core/stdcpp/typeinfo.d(147): Error: static assert: "Missing std::type_info binding for this platform"
Apr 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 10:36 AM, David Gileadi wrote:
 On 4/1/20 7:15 AM, Steven Schveighoffer wrote:
 One I can see right now that is probably not controversial is the 
 markdown one.
That switch is already enabled when building DMD and Phobos docs--enabling it required escaping a few places where existing docs accidentally had markdown syntax. However I didn't enable it for druntime docs because they won't build on my Mac*, so I can't easily compare output with the switch on and off. * src/core/stdcpp/typeinfo.d(147): Error: static assert:  "Missing std::type_info binding for this platform"
I will try to get it working on my Mac. -Steve
Apr 01
parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 4/1/20 8:24 AM, Steven Schveighoffer wrote:
 I will try to get it working on my Mac.
Thank you!
Apr 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 12:37 PM, David Gileadi wrote:
 On 4/1/20 8:24 AM, Steven Schveighoffer wrote:
 I will try to get it working on my Mac.
Thank you!
I'm working on it, but it appears the code is specifically designed NOT to build ddoc on macos. Once I fixed that error (just by ignoring it for D_Ddoc, there's literally no documentation inside the versioned statements), I got to a new set of errors. One that sticks out is: src/core/sys/darwin/mach/loader.d(974): Error: cannot implicitly convert expression 5 of type int to immutable(string) Looking at that line: /// The tradition UNIX data segment. SEG_DATA, // line 974 which is part of an untyped enum section. But an enum definition ONLY for CoreDdoc. A really bizarre error IMO. Essentially, the real SEG_DATA is defined on line 2883 in another like this: SEG_DATA = "__DATA", Which if I understand correctly should not be included at all because CoreDdoc is defined. I feel like the error is a bug. Either it's incorrect, or it's being triggered by something else and the error message is not telling me where the real problem is. I'm pretty sure this is the case, because that error appears a few times... Before I go further, I want to ask, why is this a blocking issue? If nobody can build druntime ddoc on macos anyway, why is a problem to avoid adding -preview=markdown? Or is it just that you lack another platform to test with? -Steve
Apr 01
next sibling parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 4/1/20 10:07 AM, Steven Schveighoffer wrote:
 On 4/1/20 12:37 PM, David Gileadi wrote:
 On 4/1/20 8:24 AM, Steven Schveighoffer wrote:
 I will try to get it working on my Mac.
Thank you!
I'm working on it, but it appears the code is specifically designed NOT to build ddoc on macos. Once I fixed that error (just by ignoring it for D_Ddoc, there's literally no documentation inside the versioned statements), I got to a new set of errors. One that sticks out is: src/core/sys/darwin/mach/loader.d(974): Error: cannot implicitly convert expression 5 of type int to immutable(string) Looking at that line:         /// The tradition UNIX data segment.         SEG_DATA, // line 974 which is part of an untyped enum section. But an enum definition ONLY for CoreDdoc. A really bizarre error IMO. Essentially, the real SEG_DATA is defined on line 2883 in another  like this:     SEG_DATA = "__DATA", Which if I understand correctly should not be included at all because CoreDdoc is defined. I feel like the error is a bug. Either it's incorrect, or it's being triggered by something else and the error message is not telling me where the real problem is. I'm pretty sure this is the case, because that error appears a few times... Before I go further, I want to ask, why is this a blocking issue? If nobody can build druntime ddoc on macos anyway, why is a problem to avoid adding -preview=markdown? Or is it just that you lack another platform to test with?
Yes, it's that last thing--I'm exclusively on a Mac. I guess I could set up a VM in VirtualBox or something but so far I've been too lazy/distracted to make the time for it.
Apr 01
next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 1 April 2020 at 17:12:00 UTC, David Gileadi wrote:
 Yes, it's that last thing--I'm exclusively on a Mac. I guess I 
 could set up a VM in VirtualBox or something but so far I've 
 been too lazy/distracted to make the time for it.
The way the documentation generator works at the moment is less than ideal. If doesn't really take into account `static if`, `version`, etc... The solution needs to be at the DMD level, not at the project level.
Apr 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 1:31 PM, Mathias LANG wrote:
 On Wednesday, 1 April 2020 at 17:12:00 UTC, David Gileadi wrote:
 Yes, it's that last thing--I'm exclusively on a Mac. I guess I could 
 set up a VM in VirtualBox or something but so far I've been too 
 lazy/distracted to make the time for it.
The way the documentation generator works at the moment is less than ideal. If doesn't really take into account `static if`, `version`, etc... The solution needs to be at the DMD level, not at the project level.
I don't know how to fix this. Basically, if you don't want to build the whole project as it is on each platform, you need to have special ddoc versions for things. In this case, you have enum definitions that are not defined on the platform that D builds its docs. So whoever did this replicated the entire file but just without any actual definitions, and tagged them for ddoc. I think this was the wrong approach, we should have tagged them and included the real definitions if version(CoreDdoc) was true. I've seen a few "workarounds" for generating documentable code for multiple platforms, or for projects that include other libraries but don't want to build those other libraries just for ddoc. An example of the latter is mysql-native, which defines stubs for vibe-d items for documentation, since vibe-d is optional. I wonder if the way to build the documentation is simply to build it with all possible platform definitions, and section them off. The html could have a platform selector or something that allows you to see what your platform or configuration supports. Something like a switch to dmd like: -ddoc-config=OSX -ddoc-config=Linux ddoc-config=Linux,Have_Vibed And then it generates all the docs for all those configurations based on trying each of those versions on the AST. -Steve
Apr 01
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 17:51:47 UTC, Steven Schveighoffer 
wrote:
 The way the documentation generator works at the moment is 
 less than ideal.
I don't know how to fix this.
This is why I abandoned the approach of using dmd entirely and wrote a separate doc generator with a separate parser. Then it is able to display version things like here: http://dpldocs.info/experimental-docs/arsd.simpledisplay.PosixFdReader.html vs http://dpldocs.info/experimental-docs/arsd.simpledisplay.WindowsHandleReader.html It just plain tells you it is `version(Windows) class WindowsHandleReader`.
Apr 01
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 18:04:01 UTC, Adam D. Ruppe wrote:
 This is why I abandoned the approach of using dmd entirely and 
 wrote a separate doc generator with a separate parser.
Also note: http://dpldocs.info/experimental-docs/arsd.simpledisplay.GlobalHotkey.html Trying to do that by different builds... how would you know to do custom version specifiers? What about `static if` conditions? Just showing it is the only sane way I can imagine.
Apr 01
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 2:12 PM, Adam D. Ruppe wrote:
 On Wednesday, 1 April 2020 at 18:04:01 UTC, Adam D. Ruppe wrote:
 This is why I abandoned the approach of using dmd entirely and wrote a 
 separate doc generator with a separate parser.
Also note: http://dpldocs.info/experimental-docs/arsd.simpledisplay.GlobalHotkey.html Trying to do that by different builds... how would you know to do custom version specifiers? What about `static if` conditions? Just showing it is the only sane way I can imagine.
It looks good. I have a question though. What about when you have things like this: version(OSX) version = someFunkyVersion; version(Linux) version = someFunkyVersion; /// version(someFunkyVersion) void documentMe(); does that display "someFunkyVersion" or version(OSX || Linux) or something like that? Because the incorrect thing to imply is that you have to define the version it's saying. A feature I'd like to see too (but please don't do it for just me, as I don't use your docs at the moment), is to have version filters at the top so you can see docs only relevant to your platform. Should be pretty simple JS addition. -Steve
Apr 01
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 18:21:46 UTC, Steven Schveighoffer 
wrote:
 What about when you have things like this:

 version(OSX) version = someFunkyVersion;
 version(Linux) version = someFunkyVersion;

 ///
 version(someFunkyVersion) void documentMe();

 does that display "someFunkyVersion" or version(OSX || Linux) 
 or something like that?
It'll say "someFunkyVersion", it keeps what's in the source. (that link there actually does just that - version(X11) is defined above as the default on version(linux)). What I haven't done yet is auto-link those identifiers back to the original definition, so you can actually see it and any attached ddoc comment. But even without that, actually seeing what's in the source works a lot better than just skipping it entirely in the docs!
 A feature I'd like to see too (but please don't do it for just 
 me, as I don't use your docs at the moment), is to have version 
 filters at the top so you can see docs only relevant to your 
 platform. Should be pretty simple JS addition.
Oh perhaps, but given how complicated some of the this can be. Like does a filter on `someFunkyVersion` include OSX? Does one on OSX include it? It is certainly possible, the language's feature-poor `version` thing is actually a kinda nice benefit here since it isn't too hard to recreate that logic and rebuild the chain in a doc script too. But it is just all more than it looks at first glance.
Apr 01
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 2:32 PM, Adam D. Ruppe wrote:
 On Wednesday, 1 April 2020 at 18:21:46 UTC, Steven Schveighoffer wrote:
 What about when you have things like this:

 version(OSX) version = someFunkyVersion;
 version(Linux) version = someFunkyVersion;

 ///
 version(someFunkyVersion) void documentMe();

 does that display "someFunkyVersion" or version(OSX || Linux) or 
 something like that?
It'll say "someFunkyVersion", it keeps what's in the source. (that link there actually does just that - version(X11) is defined above as the default on version(linux)).
Yeah, I suppose that's still more useful than nothing.
 A feature I'd like to see too (but please don't do it for just me, as 
 I don't use your docs at the moment), is to have version filters at 
 the top so you can see docs only relevant to your platform. Should be 
 pretty simple JS addition.
Oh perhaps, but given how complicated some of the this can be. Like does a filter on `someFunkyVersion` include OSX? Does one on OSX include it? It is certainly possible, the language's feature-poor `version` thing is actually a kinda nice benefit here since it isn't too hard to recreate that logic and rebuild the chain in a doc script too.
My expectation is that you would provide the list of versions to "turn on or off", and then use that data to determine when symbols are present. These would probably just be the OS versions I would think. Semantic processing on the version statements should be pretty straightforward since they are so limited. -Steve
Apr 01
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Apr 01, 2020 at 06:12:39PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 On Wednesday, 1 April 2020 at 18:04:01 UTC, Adam D. Ruppe wrote:
 This is why I abandoned the approach of using dmd entirely and wrote
 a separate doc generator with a separate parser.
Also note: http://dpldocs.info/experimental-docs/arsd.simpledisplay.GlobalHotkey.html Trying to do that by different builds... how would you know to do custom version specifiers? What about `static if` conditions? Just showing it is the only sane way I can imagine.
Yeah, the problem with ddoc is that it's tied to what the compiler actually compiles, so things like version() and static if throw it off because the compiler prunes entire branches from the AST before processing it. When generating docs, in theory *all* ddoc comments should emit output, and each conditional branch should add to a list of clauses attached to the ddoc output. I doubt this is feasible to implement in the current dmd code, though. T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Apr 01
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-04-01 19:51, Steven Schveighoffer wrote:

 So whoever did this 
 replicated the entire file but just without any actual definitions, and 
 tagged them for ddoc. I think this was the wrong approach, we should 
 have tagged them and included the real definitions if version(CoreDdoc) 
 was true.
That was me. Do you suggest that the Ddoc comments are moved to the actual definitions and set the `Darwin` version identifier when `CoreDdoc` is enabled? That might have been better, in this case. It's difficult to know how to deal with this the best way. Different modules solve this in different way.s We don't seem to have a standard way to deal with this. In this case it might have worked, because this module doesn't have any dependencies on other modules. But in other cases that might not be the case. You need to make sure those symbols in the other modules are available when building the docs. -- /Jacob Carlborg
Apr 01
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/2/20 2:36 AM, Jacob Carlborg wrote:
 On 2020-04-01 19:51, Steven Schveighoffer wrote:
 
 So whoever did this replicated the entire file but just without any 
 actual definitions, and tagged them for ddoc. I think this was the 
 wrong approach, we should have tagged them and included the real 
 definitions if version(CoreDdoc) was true.
That was me. Do you suggest that the Ddoc comments are moved to the actual definitions and set the `Darwin` version identifier when `CoreDdoc` is enabled? That might have been better, in this case.
Maybe. The problem with the current situation is that on MacOS those definitions are actually used elsewhere, but CoreDdoc trumps setting the Darwin version, so you get the wrong types defined here. The duplicated symbols seems prone to error (you may add a symbol to the bottom, but not to the ddoc part). Just that problem alone seems like it would be worth being able to get this compiling without duplicating everything.
 It's difficult to know how to deal with this the best way. Different 
 modules solve this in different way.s We don't seem to have a standard 
 way to deal with this. In this case it might have worked, because this 
 module doesn't have any dependencies on other modules. But in other 
 cases that might not be the case. You need to make sure those symbols in 
 the other modules are available when building the docs.
I think the standard way should be to alter symbols that are not cross-platform only when needed (i.e. functions that can't compile on other platforms) as: /// Documentation version(CorrectPlatform) void foo() { // implementation } else version(CoreDdoc) void foo(); // stub This way, things aren't spread far apart, and symbols that compile just fine on other platforms are not affected. There will be some exceptions. For instance system-level enums that have different values on different platforms. That's just going to be a hard module to maintain. -Steve
Apr 03
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 1:12 PM, David Gileadi wrote:
 Yes, it's that last thing--I'm exclusively on a Mac.
Well in that case, let's just see what happens ;) https://github.com/dlang/druntime/pull/3016 -Steve
Apr 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 1:54 PM, Steven Schveighoffer wrote:
 On 4/1/20 1:12 PM, David Gileadi wrote:
 Yes, it's that last thing--I'm exclusively on a Mac.
Well in that case, let's just see what happens ;) https://github.com/dlang/druntime/pull/3016
In almost all cases, it makes things better. Most of the examples of the differences are places where people were writing markdown not realizing it wouldn't come out that way in the ddocs. Just a couple of quirks, I'll fix those and then we can merge this. http://dtest.dlang.io/results/a3c49490a7db6ebcb0f84e9d4ef1613a0a6fcc80/53bd6f5ac68d43913111d8acbc620cc55574a1b3/ -Steve
Apr 01
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 2:57 PM, Steven Schveighoffer wrote:
 On 4/1/20 1:54 PM, Steven Schveighoffer wrote:
 On 4/1/20 1:12 PM, David Gileadi wrote:
 Yes, it's that last thing--I'm exclusively on a Mac.
Well in that case, let's just see what happens ;) https://github.com/dlang/druntime/pull/3016
In almost all cases, it makes things better. Most of the examples of the differences are places where people were writing markdown not realizing it wouldn't come out that way in the ddocs. Just a couple of quirks, I'll fix those and then we can merge this.
It's merged. Anyone want to make it the default? There were 6 modules that were different with this change. In 4 of them, the documentation looked better, as the authors of the docs were expecting markdown-like behavior without realizing it wouldn't happen. In one case, it appears that markdown interpreted a >= as the start of a blockquote (started with >). In one case, someone used underscores for marking D code instead of dashes. This subtle problem looks very similar to the right thing when reviewing the source, but looks wrong on the actual docs (just underscores come out, and all the D code is just mashed together as plain text). The markdown turned these into <hr>, which actually looked a bit better, but drew attention to the fact that the wrong marking was used (the D code was still mashed up and not highlighted). I think there is very little breakage that would happen from making this the default, and the worst thing that happens is your docs look funky until you fix them, or you find __ bugs ;) BTW, thanks to Vladimir for the auto-tester for documentation, this made the process super-simple to see what happened, especially with the diff mode. -Steve
Apr 03
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/20 1:07 PM, Steven Schveighoffer wrote:
 A really bizarre error IMO. Essentially, the real SEG_DATA is defined on 
 line 2883 in another  like this:
 
      SEG_DATA = "__DATA",
 
 Which if I understand correctly should not be included at all because 
 CoreDdoc is defined. I feel like the error is a bug. Either it's 
 incorrect, or it's being triggered by something else and the error 
 message is not telling me where the real problem is. I'm pretty sure 
 this is the case, because that error appears a few times...
Yep, it's definitely a bug. Added: https://issues.dlang.org/show_bug.cgi?id=20718 -Steve
Apr 01
prev sibling next sibling parent Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 1 April 2020 at 14:15:36 UTC, Steven Schveighoffer 
wrote:
 Any idea on when these will become permanent or be removed? We 
 are collecting quite a few of these. Which means, we are 
 currently shipping 2^11 different compilers simultaneously (I 
 know there's really less since some of them activate the 
 others).
And your list is missing `-preview=in` which is not part of a release yet. When will they be enabled ? When someone does the work to actually finish them. I've never been a fan of the `-preview` switch, simply because it tends to lead to feature which are incomplete. DIP1008 didn't work for the first year or so, and has issues at the moment with safety IIRC. rvalueref is plain broken (doesn't work with template inference). DIP25 will actually be on by default on the next release. This led to a pretty long discussion which you might be interested in: https://github.com/dlang/dmd/pull/10805 Personally I have an interest in seeing rvalueref, nosharedaccess, and perhaps dip1008, so that's what I'm going to be pushing for in the next few months whenever I get time.
Apr 01
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 1 April 2020 at 14:15:36 UTC, Steven Schveighoffer 
wrote:
 dmd '-preview=?'

 Upcoming language changes listed by -preview=name:
   =all              list information on all upcoming language 
 changes
   =dip25            implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md 
 (Sealed references)
   =dip1000          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md 
 (Scoped Pointers)
   =dip1008          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md 
 ( nogc Throwable)
   =dip1021          implement 
 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md (Mutable
function arguments)
   =fieldwise        use fieldwise comparisons for struct 
 equality
   =markdown         enable Markdown replacements in Ddoc
   =fixAliasThis     when a symbol is resolved, check alias this 
 scope before going to upper scopes
   =intpromote       fix integral promotions for unary + - ~ 
 operators
   =dtorfields       destruct fields of partially constructed 
 objects
   =rvaluerefparam   enable rvalue arguments to ref parameters
   =nosharedaccess   disable access to shared memory objects

[snip]
It would probably be good if there were a spec page for these...I remember seeing them in the Changelog, but I completely even forgot that fixAliasThis was a thing. It would also be an opportunity to get the additional documentation that will need to be added to the spec ready in advance.
Apr 01
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2020 7:15 AM, Steven Schveighoffer wrote:
    =dip25            implement 
#dip25 has been around for 4 years now. It's time to deprecate the old behaviors. We can start with that one.
Apr 02