[Issue 7417] One-definition rule for version specification - allow version expressions

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7417



--- Comment #2 from Martin Nowak <code at dawg.eu> 2013-01-30 07:41:11 PST ---
> WalterBright

>A far more robust and organized approach is to figure out just what you're trying to abstract away in these version blocks, and then abstract it away as a struct, class, function, or import. Then,

>version (B)
>feature() { return foo(); }
>else version (C)
>feature() { return foo(); }
>else version (D)
>feature() { return creature(); }
>else
>static assert(0, "version not supported");

>This is clear, simple, organized, and forces the programmer adding E to check each one of those, instead of assuming they will work.

>I know that D users will continue to try and write C style version blocks, but I will continue to try and show a better way. I also am painfully aware that druntime/phobos have turned to C style versioning, despite my exhortations. It should be fixed, not embraced.

Please do. It's an important design principle, deserves a proper name and
getting popularized.
It takes some getting used to it because it apparently contradicts other design
principles.
But we DO use it in druntime/phobos all over the place.
I hope you can write an article or give a talk about this at some point.

I do not agree though that it's the right approach for all problems.
Take ELFOBJ in DMD as an example.
>#define ELFOBJ (TARGET_LINUX || TARGET_FREEBSD || TARGET_OPENBSD || TARGET_SOLARIS)
If what you want to specialize is ELF code you need exactly this abstraction.
It solves the maintenance issue of having to restate it over and over again,
therefor I mentioned DRY.
Adding a new ELF target could use a compilation/fix/test-cycle approach and
testing has become the method of choice for most projects.

>The recent attempt to replace in the DMD source code a bunch of the operating system predefines with POSIX was a failure, and the reason for the failure was a fine example of why the C approach is inferior and why it isn't supported in D. 

I didn't follow that but as you said before it would have been naive to think
everything would just work. For POSIX to work you need two sides, a fully
compliant implementation and POSIX correct client code. This is doomed to fail
but it doesn't make POSIX a bad abstraction layer.

The problem is that forcing people to use something they feel is a bad match to
their problem won't make this popular.
This is the reason why "final switch" is a winner, it optionally allows people
to improve their code correctness but it doesn't get in the way.
It would be more fruitful to warn/error about a missing default case in an
if-else ladder.
If you thoroughly read through Dons proposal you see that he enforces to
declare all used version identifiers before usage. This would open a door for
better compile time checks. Maybe we could even check that no value combination
of the induced extern version identifiers would lead to taking a branch of an
if-else ladder.
This would be something I'd call a worthy D implementation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------