How would sf::Shader work if SFML 3 switched to "modern OpenGL"?

[Ixrec]

I haven't done very much with OpenGL, but my understanding is that if SFML 3 were to use only the "modern" shader-based pipeline instead of the fixed functions it currently uses, it would have to do things like apply a drawable's transform matrix inside a vertex shader and a drawable's (interpolated) color(s) inside a fragment shader.

It seems like this would require SFML to have default shaders and shader parameters as implementation details which users like me would have to know about when using our own shader code.  Does this seem like a problem?  Or is sf::Shader a sufficiently "advanced" feature for that to be a non-issue?

[Laurent]

It's already the case now with the non-modern OpenGL implementation, because when you use a shader you bypass the corresponding part of the fixed pipeline. The tutorial explains what you have to implement in your shader to make it work as expected by SFML.

To me this is not a problem at all, a shader has to adapt to its inputs.

[binary1248]

I think he means something like: How would SFML bind shader attributes to to a drawable's array data.

If we went ahead and made it so that sfml-graphics can still be used shader-less we would have to come up with some attribute naming convention that people would have to use in their shaders as well. Since all the gl_ stuff is reserved and will produce errors, they will probably start with sf_ or something.