May 22, 2023
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.
May 22, 2023
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!
May 23, 2023

On Sunday, 21 May 2023 at 18:43:32 UTC, Dennis wrote:

>

D's version() statement deliberately does not allow composing version conditions with boolean operators ! || &&, in order to avoid C's #ifdef hell. This is a controversial design decision though, because some people don't like the resulting verbosity you sometimes get. Discussions about this come up now and then, see for example Issue 7417 and its duplicates.

The most recent incarnation of this comes from this Phobos PR proposing a library solution:
std.compiler.Version

import std.compiler;

static if (Version.D_InlineAsm_X86 || Version.D_InlineAsm_X86_64)
{
    version = UseX86Assembly;
}

I don't expect this to get approval though, I said in the PR discussion:

>

I'll bring this up in the next DLF monthly meeting, but without new compelling arguments, I don't expect a different outcome. If you can demonstrate problems (other than it not looking nice) in existing projects that the current logic causes, you'll have a stronger case.

So far I haven't received any real code examples, so I'm asking here:

Do you have any examples of existing projects (on github, dub, etc.) that either:

  • demonstrate version algebra done well
  • use a Version-like template successfully
  • have real problems with existing version() statements (besides 'it looks ugly')

Please reply with links and don't rekindle the old arguments. I can't stop you, but know that it will only be counter-productive.

One thing that is not mentioned is the grammar of version algebra...what would be allowed ? Do we want things like

version(mixin(someCtfeCall(())

How would be handled the fact that

enum BigEndian = 0.123;

is ATM legal, i.e identifiers can be both expressions and sealed version identifiers ?

There are already bugs caused by the fact that static ifs can introduce versions... it's probably not worth introducing version algebra until those get fixed.

May 23, 2023

On Tuesday, 23 May 2023 at 10:01:37 UTC, Basile B. wrote:

>

On Sunday, 21 May 2023 at 18:43:32 UTC, Dennis wrote:
[...]

One thing that is not mentioned is the grammar of version algebra...what would be allowed ? Do we want things like

version(mixin(someCtfeCall(())

How would be handled the fact that

enum BigEndian = 0.123;

is ATM legal, i.e identifiers can be both expressions and sealed version identifiers ?

There are already bugs caused by the fact that static ifs can introduce versions... it's probably not worth introducing version algebra until those get fixed.

image for the children : https://imgflip.com/i/7mropf

May 23, 2023
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)
1 2 3
Next ›   Last »