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

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.

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"

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.

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

On 4/1/20 8:24 AM, Steven Schveighoffer wrote:
> I will try to get it working on my Mac.

Thank you!

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

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.

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.

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