Subject of the issue
#2486 and #2494 remove default constructors for sf::Text and sf::Sprite which are types that are not usable unless they contain a pointer to a valid resource. Those resources are an sf::Font and a sf::Texture respectively. The rationale is that by allowing for default construction, we're making it too easy for users to write bugs where they forget to assign the correct resource to a given type. By removing the default constructor, we force users to provide that resource upon construction so we can be sure that instances of these types are valid at all points in time. The convenience of a default constructor is not worth the potentially incorrect code someone may write. It's not possible to set these pointers to nullptr after construction so why let them be null upon construction?
Here's a list of types that may need to get this same treatment before SFML 3.0.0.
I believe there are no more than just these three but I could have missed one. sf::Sound is harder because its copy assignment operator will set the underlying sf::SoundBuffer to nullptr so it actually can have its resource set to nullptr after construction unlike the other two. A solution for sf::Sound may require altering how copy semantics work.
Subject of the issue
#2486 and #2494 remove default constructors for
sf::Textandsf::Spritewhich are types that are not usable unless they contain a pointer to a valid resource. Those resources are ansf::Fontand asf::Texturerespectively. The rationale is that by allowing for default construction, we're making it too easy for users to write bugs where they forget to assign the correct resource to a given type. By removing the default constructor, we force users to provide that resource upon construction so we can be sure that instances of these types are valid at all points in time. The convenience of a default constructor is not worth the potentially incorrect code someone may write. It's not possible to set these pointers tonullptrafter construction so why let them be null upon construction?Here's a list of types that may need to get this same treatment before SFML 3.0.0.
sf::Text(Remove bugpronesf::Textconstructor #2486)sf::Sprite(Remove defaultsf::Spriteconstructor #2494)sf::Sound(Remove sound default constructor #2640)I believe there are no more than just these three but I could have missed one.
sf::Soundis harder because its copy assignment operator will set the underlyingsf::SoundBuffertonullptrso it actually can have its resource set tonullptrafter construction unlike the other two. A solution forsf::Soundmay require altering how copy semantics work.