Thanks for the feedback!

I believe this shouldn't be required, as the first overload variant (with optional LOD) still provides coverage for this case. The purpose of this patch was to remove a redundant, conflicting, definition of the function which utilised Vec<T, n> syntax for the 1D case, which was intended to add support for implicit casts from float to integer coordinates, though these variants are not needed as scalar type T can be used directly.

The second case, was also caused by ambiguity when 3 integer arguments were passed in, as this could either refer to the first function (with optional LOD), or equally, the variant with default offset was also valid. So making the offset non-default ensures that the first two cases (2 and 3 arguments) always default to the first function, and the 4-argument case defaults to second function.

Function 1):

template<typename S, typename T, access A>
inline vec<S, 4> _texelFetch_internal(thread _mtl_combined_image_sampler_1d<S, A> tex,
                                      T texel,
                                      uint lod = 0)
{
  float w = tex.texture->get_width();
  if (texel >= 0 && texel < w) {
    return tex.texture->read(uint(texel));
  }
  else {
    return vec<S, 4>(0);
  }
}

Provides an overload for
2 arguments texelFetch(Texture, TexelCoord)
3 arguments texelFetch(Texture, TexelCoord, LOD)

The second function (with default offset removed):

template<typename S, typename T, access A>
inline vec<S, 4> _texelFetch_internal(thread _mtl_combined_image_sampler_1d<S, A> tex,
                                      T texel,
                                      uint lod,
                                      T offset)
{
  float w = tex.texture->get_width();
  if ((texel + offset) >= 0 && (texel + offset) < w) {
    /* LODs not supported for 1d textures. This must be zero. */
    return tex.texture->read(uint(texel + offset), 0);
  }
  else {
    return vec<S, 4>(0);
  }
}

Provides coverage for the texelFetchOffset(Tex, TexelCoord, LOD, Offset) case with 4 arguments.

Adding in the macro arguments would always force 3 arguments to be used, which makes sense for the sampler 1D/2D/3D cases, however, for samplerBuffer, texelFetch in GLSL does not expose an LOD parameter, so this could cause secondary issues. The LOD parameter could however be made non-optional for the other cases, if this is preferred.

But please let me know if I've misunderstood!