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