On 5/22/2023 4:06 AM, Hipreme wrote:
> Yes, I do understand. Although I prefer `static assert` to not be used, but the runtime `assert`. I have done a port of the druntime and the `static assert` usage really is a pain since there is just a plain lot of code which is not used by me, but only for its existence, it causes a compilation error.

Runtime assert doesn't work at module scope. Also, it's usually better to catch porting errors at compile time, rather than after the code was shipped.


> I think the feature based is cleaner to read most of the time (and scalable), I have done a good refactor in a lot of D code already using that, and IMO, it did done wonders into making the code intention crystal clear even for non maintainers. This is a thing which I've come to understand the decision of not allowing boolean operators on `version`. Maybe if there was a construct for allowing **only version declaration** with boolean operators like:
> `version RelaxedSystems = version(Windows && linux && !OSX)` (it would not be global as the `version` is right now. i.e: not allow this syntax to be used standalone.

As I mentioned elsewhere, that goes wrong, too.


> So, the operators aren't really the hell that causes the `#ifdef` hell as you said. The problem are 2:
> 
> 1: They being defined over all files. While trying to port newlibc, I've come to find a type to be defined over 6 files. Which meant I really went jumping from a file to file until I was able to find how the type were defined. This is a real problem since the type is not self contained so it is super hard to look. How to solve that: D has solved! Just make the `version =` not spam into multiple files.

Yup. D does not "import" versions from other modules. This was another crucial design decision that has paid off handsomely. How miserable it is in C to figure out where a #define is coming from in the typical rat's nests of #include's, or even if it is #define'd at all.


> 2: Operators: they don't really make sense when other people are looking into them, which is solved by having the feature named, so, enforcing the naming to use the operators could be a problem solving in the syntax.

Most people read code a hundred times more than they write code, so being a bit verbose to improve reading is a worthwhile tradeoff.


> Since they aren't
> global, they are painful to keep writing all the time the same thing (I've tried
> doing that on directx-d binding and omg, I basically got a 8 line headers in
> almost all files, sure, it is easier to read than C, but it was painful writing
> them).

The technique, as I mentioned in the upstream post, is to have the feature versions in one file, have `extraFunctionality()` defined as doing something or a noop in that file, and just call `extraFunctionality()` elsewhere.

I should write an article about this.

On 5/22/2023 4:23 AM, Adam D Ruppe wrote:
> http://dpldocs.info/this-week-in-d/Blog.Posted_2023_02_20.html#static-assert-patterns-arguably-harmful-for-porting

A good article!

On Monday, 22 May 2023 at 14:10:24 UTC, Timon Gehr wrote:
> On 22.05.23 13:46, Petar Kirov [ZombineDev] wrote:
>> On Monday, 22 May 2023 at 11:23:32 UTC, Adam D Ruppe wrote:
>>> On Monday, 22 May 2023 at 08:21:50 UTC, Walter Bright wrote:
>>>> Personally, I like to make the core code version-independent and OS-independent and hide the variances in separate modules. Isn't foo() clean looking?
>>>
>>> http://dpldocs.info/this-week-in-d/Blog.Posted_2023_02_20.html#static-assert-patterns-arguably-harmful-for-porting
>> 
>> I agree with you that having the option of using run-time guards like  `assert(0)` / `throw new NotImplementedEx()` and even using empty declarations at compile-time is very convenient in practice to get going with a port. On the other hand, I also find a great amount in being able to get an almost complete list of things that I need to fix at compile-time in terms of planning my work.
>
> ```d
> version(Windows) foo();
> else version(linux) bar();
> else version(fail_early) static assert(0);
> else assert(0);
> ```
>
> :o)

Two issues:
* Requires changing all existing code
* Doesn't work for declarations (e.g. defining an `enum`, `struct`, etc. at module scope)