On Tue, Jul 26, 2022 at 10:52:29AM +0000, Andrey Zherikov via Digitalmars-d wrote: [...]
> As a library developer I want to provide some SLA to the users: I guarantee that my library will be successfully built by all versions of all compilers (ldc,gdc,dmd) that are one year old or newer. The thing is that compilers evolve (they got new features, bug fixes etc) and I want my codebase evolve with them. I can easily check what compiler is used by `version(DigitalMars)` e.g.. But how should I check that a specific feature is added to compiler/phobos or a specific bug is fixed?

	static if (__VERSION__ == 2098L) {
		... // 2.098-specific code
	}
	static if (__VERSION__ == 2100L) {
		... // 2.100-specific code
	}
	// and so on


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and those who can't.

On Tue, Jul 26, 2022 at 03:19:44PM +0000, Andrey Zherikov via Digitalmars-d wrote:
> On Tuesday, 26 July 2022 at 13:27:55 UTC, H. S. Teoh wrote:
[...]
> > ```
> > 	static if (__VERSION__ == 2098L) {
> > 		... // 2.098-specific code
> > 	}
> > 	static if (__VERSION__ == 2100L) {
> > 		... // 2.100-specific code
> > 	}
> > 	// and so on
> > ```
> 
> This is discouraged usage according to Walter, isn't it?

I guess so. :-D

So maybe we need a DIP to add feature-based version identifiers, e.g.:

	version(fixed12345) { ... /* bug 12345 is fixed */ }
	version(dip1000) { ... }
	version(intpromote) { ... }

and so on.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

On Tuesday, 26 July 2022 at 17:06:17 UTC, H. S. Teoh wrote:
> [snip]
>
> I guess so. :-D
>
> So maybe we need a DIP to add feature-based version identifiers, e.g.:
>
> 	version(fixed12345) { ... /* bug 12345 is fixed */ }
> 	version(dip1000) { ... }
> 	version(intpromote) { ... }
>
> and so on.
>
>
> T

The bottom two are a bit separate. It makes perfect sense to add predefined versions for preview statements (it may even make sense to include even more than that, e.g. version statement for other D features that people may want to disable, but that's neither here nor there and a bit beyond the scope). I don't think it needs a DIP for that.

Bug fixes are a bit more annoying because there are thousands of them. I would still need to look up what bug 12345 was, even though it is at least more specific than the specific a DMD version. I think checking whether the buggy code is fixed with a traits _compiles is a little more obvious.

On 7/26/2022 3:52 AM, Andrey Zherikov wrote:
> But how should I check that a specific feature is added to compiler/phobos or a specific bug is fixed?

Create a single "configuration module", which has a section for each version:

--------
module config;

version (DigitalMars)
{
    import digitalmars;
}
else version (LDC)
{
    import ldc;
}
else version (GDC)
{
    import gdc;
}
else
{
    static assert(0, "unsupported system");
}
---------

Now, in digitalmars.d and ldc.d and gdc.d, do what it takes to make that configuration work for your code.

This makes it really easy to concentrate, say, in ldc.d, just on ldc's characteristics. Rather than having to constantly confuse yourself with which configuration is compiling what code.

It also immediately points out when the code is being built for a version you have not anticipated.

On 7/26/2022 10:33 AM, jmh530 wrote:
> I think checking whether the buggy code is fixed with a traits _compiles is a little more obvious.

And a little more obvious.