-preview switches

Steven Schveighoffer schveiguy at gmail.com
Fri Apr 3 15:28:23 UTC 2020


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


More information about the Digitalmars-d mailing list