Tracking features not in upstream D

[quickfur]

Continuing from https://github.com/orgs/opendlang/discussions/2

Is there a webpage or wiki page or somewhere in the website repo that we can use to keep a list of features OpenD has that isn't in upstream D? Currently here are the ones I know of:

• String interpolation (the tuple version)
• Octal literals are back
• version(D_OpenD) to identify the forked compiler

[adamdruppe]

Hit refresh on the roadmap, im editing it on my computer, i guess i should git push that periodically too.

But yeah definitely want it on the website, there's a link there for changes from upstream and the roadmap is a kind of todo list

[quickfur]

What do you want to do with the module renaming from - to _? Figure I could knock that up pretty quickly.

[quickfur]

Also, I could probably knock up the -release fix, if it's just a matter of using different defaults and doesn't require a whole lot of new code.

[adamdruppe]

Yeah that module rename things hould be a quick hack. The point is just when you dmd 1-test.d and it doesn't have a module decl, it considers it to be just... idk __1_test was my first thought. Just so it compiles without error. But you should NOT be able to import a module unless it has an explicit module declaration (tho that's a breaking change we still dont want anybody relying on this janky hack).

And -release actually i kinda want that to forward to ldmd2 - to cement the idea that ldc is the release build compiler. But obviously it shouldn't turn off bounds checks and stuff. In the short term i'd be ok with it doing absolutely nothing. If you wanna turn off boundschecks and contracts etc, there' dindividual switches for that.

[adamdruppe]

BUT - druntime might depend on -release doing what it does now! so use some caution there.

[quickfur]

Well, dmd already uses __stdin when compiling stuff from stdin and there's no filename to base the module name off of. (This is the fault of yours truly. :-P) So maybe we should just say any module name that starts with __ is reserved for compiler internal use, then we can just do __1_blah, __2_blah, etc..

This will break quite a bit of my code, though. Especially older code that relies on dmd using the filename as the module name by default because I was too lazy to type in the module declaration.