On 7/22/2022 5:33 PM, Hipreme wrote:
> But, how one would approach when the feature is version dependent? This becomes a lot harder to reason about, the version number could mean anything. Specially approaching bindings, which other languages already has that convention of making/not making available functions based on version, it becomes even harder when this function can be enabled/disabled and is even build version dependent

New versions are not just numbers. They are an arbitrary collection of new features and modified features. Nobody, not even the author, will remember which feature goes with which version number.

My recommendation is to use version identifiers for each of those features that changed that matter to your program. It's rarely more than a handful. It'll make your code a pleasure to read, too.

On Sat, Jul 23, 2022 at 12:33:36AM +0000, Hipreme via Digitalmars-d wrote:
> On Friday, 22 July 2022 at 18:22:52 UTC, Walter Bright wrote:
> > On 7/22/2022 6:36 AM, Hipreme wrote:
> > > version(SDL.2.5.5)
> > > ...
> > > version(SDL.2.5.0) //Ok
> > > version(SDL.2.4) //not ok
> > 
> > The reader has no idea what actual feature is being turned on or off.
> 
> I understand your point. But there exists a problem. The reason why version was been created seems basically:
> 
> ```d
> version(FeatureA){}
> version(FeatureB){}
> ```
> 
> Trying to use numbers on version doesn't seem to be what you have planned.  I believe the naming could be `feature(A)` instead of version because it would make a lot more sense. In my case, I have been coding a game engine which you can turn off or on a lot of features like: `version(JSONParsing)` `version(XMLParsing)`, which it is easy to understand exactly what is happening, but it actually does not really reflect what a version is.
> 
> But, how one would approach when the feature is version dependent? This becomes a lot harder to reason about, the version number could mean anything. Specially approaching bindings, which other languages already has that convention of making/not making available functions based on version, it becomes even harder when this function can be enabled/disabled and is even build version dependent
[...]

Maybe something like this?

	version(build1234) {
		version = FeatureA;
		version = FeatureB;
		// etc.
	}

	version(build1235) {
		version = FeatureA;
		version = FeatureC;
		// etc.
	}

	...

	version(FeatureA) { ... /* feature A implementation here */ }
	version(FeatureB) { ... /* feature B implementation here */ }
	// etc.


T

-- 
What's an anagram of "BANACH-TARSKI"?  BANACH-TARSKI BANACH-TARSKI.

On 7/22/2022 6:31 PM, James Blachly wrote:
> I find this very insightful; the practical consequences of well-meaning policies are often surprising and frequently the complete opposite of the original policy's intent.

It brings it into the forum where I can explain how to achieve better results than the same old chaotic way C does it.

I've lived with the C way for a loooong time. Just take a look at the C system .h files on your system. I know people will treat the version way skeptically at first, but give it a try.

On 7/22/2022 8:06 PM, H. S. Teoh wrote:
> Maybe something like this?
> 
> 	version(build1234) {
> 		version = FeatureA;
> 		version = FeatureB;
> 		// etc.
> 	}
> 
> 	version(build1235) {
> 		version = FeatureA;
> 		version = FeatureC;
> 		// etc.
> 	}
> 
> 	...
> 
> 	version(FeatureA) { ... /* feature A implementation here */ }
> 	version(FeatureB) { ... /* feature B implementation here */ }
> 	// etc.

Awkward since you cannot import versions from other modules.

On 24/07/2022 7:53 AM, Walter Bright wrote:
> Awkward since you cannot import versions from other modules.

Perhaps we should be changing that.

It does seem to be a unnecessary limitation given that an enum can be used in its place.

On 7/22/2022 9:24 PM, Andrey Zherikov wrote:
> Unfortunately as you know people don't care about what you discourage or encourage. People just try to express their intent using those language structs that are the best for their needs and nothing prevents them from writing this right now:
> 
> ```d
> static if (defined(_MSC_VER) && (_MSC_VER > 600) && !defined(__INTERIX))
> {
>    static if(defined(_WIN32_WCE))
>       alias fdopen = (fd,mode) {}; /* No fdopen() */
>    else
>       alias fdopen = _fdopen;
> }
> ```
> 
> (I took this example from [zlib](https://github.com/madler/zlib/blob/master/zutil.h#L177))

`defined` doesn't work in D.

The idea is to make the wrong way unattractive and clumsy enough that people will look for a better way, which we provide.

BTW, I've been through the zlib .h files, in the course of dogfooding it with ImportC. Every ugly practice I complain about with #if's is in full display there.

Here's another gem from your link:

#if defined(STDC) && !defined(HAVE_MEMCPY) && !defined(NO_MEMCPY)
#  define HAVE_MEMCPY
#endif

It's just madness.

This is very clever, thanks for posting it! I would never have thought of it.

I always enjoy the discovery of these kinds of gems.

But I can't recommend this particular usage, because it isn't the right way to do versioning :-)

On 7/23/2022 1:08 PM, rikki cattermole wrote:
> 
> On 24/07/2022 7:53 AM, Walter Bright wrote:
>> Awkward since you cannot import versions from other modules.
> 
> Perhaps we should be changing that.

1. then you can't tell which versions are active
2. circular imports become hell


> It does seem to be a unnecessary limitation given that an enum can be used in its place.

Yes, and when that was done in druntime it produced baffling issues because of circular imports. The problems got dumped in my lap. I yanked it all out and did it right. No problems since.

On Sunday, 24 July 2022 at 02:24:39 UTC, Walter Bright wrote:

> Yes, and when that was done in druntime it produced baffling issues because of circular imports. The problems got dumped in my lap. I yanked it all out and did it right. No problems since.

Choosing a different set of problems never results in no problems.