Added support for bvecX not operator

[KaruroChori]

Added support for the missing not operator (only for boolean vectors).

[ZXShady]

Is this needed? we have glm::not_ which follows GLSL specification

[KaruroChori]

I think so? https://en.cppreference.com/w/cpp/language/operator_logical
and or and not are valid replacements for && || and ! under the C++ standard specs.
Not having the not operator working artificially makes valid glsl not compatible in C++.

For example, this is valid with my patch applied, else not:

if( all(cond) || all(not(cond)) ) s*=-1.0;

So yes, I would say having it is a good idea in place of glm::not_ unless I am missing something.

[ZXShady]

I think so? https://en.cppreference.com/w/cpp/language/operator_logical
and or and not are valid replacements for && || and ! under the C++ standard specs.

they are second class they are alternatives.

Not having the not operator working artificially makes valid glsl not compatible in C++.

For example, this is valid with my patch applied, else not:

if( all(cond) || all(not(cond)) ) s*=-1.0;

So yes, I would say having it is a good idea in place of glm::not_ unless I am missing something.

I don't think glm allows exact copy pasting of code into C++ due to language differences. glm tries to

and the fix is just this

> if( all(cond) || all(not_(cond)) ) s*=-1.0;

notice the _ in not_ and now it compiles.

also with your patch code like this compiles

if(any(not vec))

and if we are following GLSL spec then this code should not compile.

I don't think it is important we have GLSL not function instead of ! being overloaded for vectors in both GLSL and GLM.

also having 2 functions for the same thing is weird, have one or the other and GLM uses GLSL not function instead.

tldr just use glm::not_ (note the _ because not is a reserved keyword)

[KaruroChori]

Sorry but I am really having a hard time following your points.

they are second class they are alternatives.

Even if, then what?
not is the reserved keyword used as alternative for !. The semantic of such operator is logical negation.
The library currently offers component-based overloads for both or and and, so it does make perfect sense to support the unary not.
Even excluding gsls-related considerations about code compatibility, it does simply make sense to have an idiomatic C++ implementation.

I will agree that some of the digraphs are not often used in the modern world of unicode, but I don't quite get where your "second class" label is coming from to be honest. They are there, the standard describes them as fully interchangeable, people use them, so...

I don't think glm allows exact copy pasting of code into C++ due to language differences.

Sure, I agree, but why artificially introducing some when it is not needed?

notice the _ in not_ and now it compiles.

Yes, but why would anyone able to choose pick the underscore in place of same code?

and if we are following GLSL spec then this code should not compile.

Valid point, but I see two problems there:

1. Personally, I think in general it is more acceptable to have C++ code extending glsl, compared to having glsl features not matching.
2. What really matters is that it is not a regression introduced by my code, it already existed before.

From func_vector_relational.inl around line 57

	template<length_t L, qualifier Q>
	GLM_FUNC_QUALIFIER GLM_CONSTEXPR bool any(vec<L, bool, Q> const& v)
	{
		bool Result = false;
		for(length_t i = 0; i < L; ++i)
			Result = Result || v[i];
		return Result;
	}

If we want it removed, a different PR might do that (alongside any other invalid overload which has been defined).

also having 2 functions for the same thing is weird

I agree, not_ should be set as deprecated and scheduled for removal in some far point in the future in my opinion.

[ZXShady]

You are correct, indeed && and || are not defined in GLSL, so this makes sense to be added as well, since glm already extends the vector class

[christophe-lunarg]

Do GLM actually support && and || as a "core" feature while this is not supported by the GLSL spec?
If that's the case, it's a mistake.

I followed the principale that the "core" implementation follows as strictly as possible the GLSL spec. Everything else is "extensions".

So this has a place as an extension.

[KaruroChori]

Yes it does, there is a mostly full coverage of component-wise operators which are not defined in the standard.
I would be sad to see them go, and it would most likely break downstream code, but strictly speaking you are right.
https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.60.pdf page 124 its seems like glsl has no support for them.

They have been there basically forever: a257beb

[ZXShady]

I changed my opinion on it, and this feature doesn't hurt.

[christophe-lunarg]

• The logical binary operators and (&&), or (||), and exclusive or (^^) operate only on two
Boolean expressions and result in a Boolean expression. And (&&) will only evaluate the right
hand operand if the left hand operand evaluated to true. Or (||) will only evaluate the right
hand operand if the left hand operand evaluated to false. Exclusive or (^^) will always evaluate
both operands.
• The logical unary operator not (!). It operates only on a Boolean expression and results in a
Boolean expression. To operate on a vector, use the built-in function not.

Erm, pretty unfortunate, extensions have been the way to go for this... :/
Not sure it's still the case because tools have become much better, but people used to use GLM to debug their GLSL code in C++.

I would pretty much a 2015 commit, a late game commit as GLM started about in 2005 and has been idle since 2020...