version(number) is completely useless

[H. S. Teoh]

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.