compiler flag for "preview all"

Bruce Carneal bcarneal at gmail.com
Tue Jun 30 20:26:39 UTC 2020


On Tuesday, 30 June 2020 at 19:55:40 UTC, Dennis wrote:
> On Monday, 29 June 2020 at 23:31:16 UTC, Bruce Carneal wrote:
>> So, any objections to preview=all meaning "enable all known 
>> preview items"?
>
> I wouldn't object, but I wouldn't find 'all *known* preview 
> items' useful since the status of the switches varies a lot.
>
> I personally try to enable dip25, dip1000, fieldwise, markdown, 
> fixAliasThis, intpromote, and dtorfields for my projects. I 
> especially like markdown in DDoc, and dip25+dip1000 enabling 
> @safe use of stack memory.
>
> I don't use the following switches:
>
> nosharedaccess: tried it, but it gave some compile errors I 
> couldn't be bothered to fix
> rvaluerefparam: cool feature, but DIP is in 'GitHub gist' state 
> (not even draft review), so it's not certain this will actually 
> become part of the language
> dip1008: I don't need @nogc Exceptions it, from what I heard 
> it's in a buggy state
> dip1021: useless switch that gives 100% false positives (see 
> DIP review). I tried to enable it, it gave a compile error in 
> Phobos std.uni.CowArray, and ended in a dmd segfault

For me, the marquee use case of --preview=all is automated 
compiler testing.  It should help build an ICE machine.

Given the less-than-baked status of many of the components I'd 
expect all prudent developers will agree with you that preview 
features should be used cautiously if at all.

Still, if you want to look over the horizon you can.  At the 
least the bugs uncovered can be fed to the compiler crew.







More information about the Digitalmars-d mailing list