Will specialization of std:: function templates for user-defined types be no longer allowed in C++20?

Clash Royale CLAN TAG#URR8PPP

up vote
6
down vote

favorite

1

Quote from cppreference.com:

Adding template specializations

It is allowed to add template specializations for any standard library |class (since C++20)| template to the namespace std only if the declaration depends on at least one program-defined type and the specialization satisfies all requirements for the original template, except where such specializations are prohibited.

Does it mean, that starting from C++20, adding specializations of function templates from std namespaces for user-defined types will be no longer allowed? If so, it implies that many pieces of existing code can break, doesn't it? (It seems to me to be kind-of a "radical" change.) Moreover, it will inject into such codes undefined behavior, which will not trigger compilations errors (warnings hopefully will).

c++ std template-specialization function-templates c++20

share|improve this question

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
  – Matthieu Brucher
  54 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  out of curiosity: did you ever feel like providing a specialization for std::function ?
  – user463035818
  29 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @user463035818 functions in namespace std::, not std::function, which is a class template.
  – Caleth
  25 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth misread the title ;)
  – user463035818
  23 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
  – Daniel Langr
  4 mins ago
  
  

  
  
  
  

add a comment | 

up vote
6
down vote

favorite

1

Quote from cppreference.com:

Adding template specializations

It is allowed to add template specializations for any standard library |class (since C++20)| template to the namespace std only if the declaration depends on at least one program-defined type and the specialization satisfies all requirements for the original template, except where such specializations are prohibited.

Does it mean, that starting from C++20, adding specializations of function templates from std namespaces for user-defined types will be no longer allowed? If so, it implies that many pieces of existing code can break, doesn't it? (It seems to me to be kind-of a "radical" change.) Moreover, it will inject into such codes undefined behavior, which will not trigger compilations errors (warnings hopefully will).

c++ std template-specialization function-templates c++20

share|improve this question

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
  – Matthieu Brucher
  54 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  out of curiosity: did you ever feel like providing a specialization for std::function ?
  – user463035818
  29 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @user463035818 functions in namespace std::, not std::function, which is a class template.
  – Caleth
  25 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth misread the title ;)
  – user463035818
  23 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
  – Daniel Langr
  4 mins ago
  
  

  
  
  
  

add a comment | 

up vote
6
down vote

favorite

1

up vote
6
down vote

favorite

1

1

Quote from cppreference.com:

Adding template specializations

It is allowed to add template specializations for any standard library |class (since C++20)| template to the namespace std only if the declaration depends on at least one program-defined type and the specialization satisfies all requirements for the original template, except where such specializations are prohibited.

Does it mean, that starting from C++20, adding specializations of function templates from std namespaces for user-defined types will be no longer allowed? If so, it implies that many pieces of existing code can break, doesn't it? (It seems to me to be kind-of a "radical" change.) Moreover, it will inject into such codes undefined behavior, which will not trigger compilations errors (warnings hopefully will).

c++ std template-specialization function-templates c++20

share|improve this question

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

Quote from cppreference.com:

Adding template specializations

It is allowed to add template specializations for any standard library |class (since C++20)| template to the namespace std only if the declaration depends on at least one program-defined type and the specialization satisfies all requirements for the original template, except where such specializations are prohibited.

Does it mean, that starting from C++20, adding specializations of function templates from std namespaces for user-defined types will be no longer allowed? If so, it implies that many pieces of existing code can break, doesn't it? (It seems to me to be kind-of a "radical" change.) Moreover, it will inject into such codes undefined behavior, which will not trigger compilations errors (warnings hopefully will).

c++ std template-specialization function-templates c++20

c++ std template-specialization function-templates c++20

share|improve this question

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

share|improve this question

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

share|improve this question

share|improve this question

edited 51 mins ago

edited 51 mins ago

edited 51 mins ago

asked 59 mins ago

Daniel Langr

5,3082039

asked 59 mins ago

Daniel Langr

5,3082039

asked 59 mins ago

Daniel Langr

5,3082039

5,3082039

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
  – Matthieu Brucher
  54 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  out of curiosity: did you ever feel like providing a specialization for std::function ?
  – user463035818
  29 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @user463035818 functions in namespace std::, not std::function, which is a class template.
  – Caleth
  25 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth misread the title ;)
  – user463035818
  23 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
  – Daniel Langr
  4 mins ago
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
  – Matthieu Brucher
  54 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  out of curiosity: did you ever feel like providing a specialization for std::function ?
  – user463035818
  29 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @user463035818 functions in namespace std::, not std::function, which is a class template.
  – Caleth
  25 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth misread the title ;)
  – user463035818
  23 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
  – Daniel Langr
  4 mins ago
  
  

  
  
  
  

Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
– Matthieu Brucher
54 mins ago

Removed my previous comment, I would trust en.cppreference.com/w/cpp/language/extending_std
– Matthieu Brucher
54 mins ago

out of curiosity: did you ever feel like providing a specialization for std::function ?
– user463035818
29 mins ago

out of curiosity: did you ever feel like providing a specialization for std::function ?
– user463035818
29 mins ago

@user463035818 functions in namespace std::, not std::function, which is a class template.
– Caleth
25 mins ago

@user463035818 functions in namespace std::, not std::function, which is a class template.
– Caleth
25 mins ago

@Caleth misread the title ;)
– user463035818
23 mins ago

@Caleth misread the title ;)
– user463035818
23 mins ago

@Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
– Daniel Langr
4 mins ago

@Caleth I didn't want to make the title so long, that's why the space is there. Admit it might be confusing.
– Daniel Langr
4 mins ago

add a comment | 

2 Answers
2

active

oldest

votes

up vote
5
down vote

Not really that radical. This change is based on this paper from Walter E. Brown. The paper goes into rationale rather deeply, but ultimately it boils down to this:

1. Specialization of function templates is rather poor as a customization point. Overloading and ADL are much better in that regard. There are other customization points discussed in the paper as well.


2. The standard library doesn't rely on this poor customization point too much already.


3. The wording change that's put into place actually permits adding entire declarations to namespace std (not just specializations) where it's explicitly permitted. So now there are better customization points.

Given #1 and #2, it's rather unlikely existing code will break. Or at least, not enough for this to be a major problem. Code that used auto and register also "broke" in the past, but that minuscule amount of C++ code didn't stop progress.

share|improve this answer

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

add a comment | 

up vote
4
down vote

As it stands now it definitly looks that way. The current draft states

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.

And it looks like the paper Thou Shalt Not Specialize std Function Templates! by Walter E. Brown is responsible for it. In it he details an number of reason why this should be changed such as

• Herb Sutter: “specializations don’t participate in overloading. [...] If you want to customize a function base template and want that customization to participate in overload resolution (or, to always be used in the case of exact match), make it a plain old function, not a specialization. And, if you do provide overloads, avoid also providing specializations.”


• David Abrahams: “it’s wrong to use function template specialization [because] it interacts in bad ways with overloads. [...] For example, if you specialize the regular std::swap for std::vector<mytype>&, your specialization won’t get chosen over the standard’s vector specific swap, because specializations aren’t considered during overload resolution.”


• Howard Hinnant: “this issue has been settled for a long time. . . . Disregard Dave’s expert opinion/answer in this area at your own peril.”


• Eric Niebler: “[because of] the decidedly wonky way C++ resolves function calls in templates. . . , [w]e make an unqualified call to swap in order to find an overload that might be defined in [...] associated namespaces[...] , and we do using std::swap so that, on the off-chance that there is no such overload, we find the default version defined in the std namespace.”


• High Integrity C++ Coding Standard: “Overload resolution does not take into account explicit specializations of function templates. Only after overload resolution has chosen a function template will any explicit specializations be considered.”

share|improve this answer

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52760580%2fwill-specialization-of-std-function-templates-for-user-defined-types-be-no-lon%23new-answer', 'question_page');

);

Post as a guest

Name Email

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
5
down vote

Not really that radical. This change is based on this paper from Walter E. Brown. The paper goes into rationale rather deeply, but ultimately it boils down to this:

1. Specialization of function templates is rather poor as a customization point. Overloading and ADL are much better in that regard. There are other customization points discussed in the paper as well.


2. The standard library doesn't rely on this poor customization point too much already.


3. The wording change that's put into place actually permits adding entire declarations to namespace std (not just specializations) where it's explicitly permitted. So now there are better customization points.

Given #1 and #2, it's rather unlikely existing code will break. Or at least, not enough for this to be a major problem. Code that used auto and register also "broke" in the past, but that minuscule amount of C++ code didn't stop progress.

share|improve this answer

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

add a comment | 

up vote
5
down vote

Not really that radical. This change is based on this paper from Walter E. Brown. The paper goes into rationale rather deeply, but ultimately it boils down to this:

1. Specialization of function templates is rather poor as a customization point. Overloading and ADL are much better in that regard. There are other customization points discussed in the paper as well.


2. The standard library doesn't rely on this poor customization point too much already.


3. The wording change that's put into place actually permits adding entire declarations to namespace std (not just specializations) where it's explicitly permitted. So now there are better customization points.

Given #1 and #2, it's rather unlikely existing code will break. Or at least, not enough for this to be a major problem. Code that used auto and register also "broke" in the past, but that minuscule amount of C++ code didn't stop progress.

share|improve this answer

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

add a comment | 

up vote
5
down vote

up vote
5
down vote

Not really that radical. This change is based on this paper from Walter E. Brown. The paper goes into rationale rather deeply, but ultimately it boils down to this:

1. Specialization of function templates is rather poor as a customization point. Overloading and ADL are much better in that regard. There are other customization points discussed in the paper as well.


2. The standard library doesn't rely on this poor customization point too much already.


3. The wording change that's put into place actually permits adding entire declarations to namespace std (not just specializations) where it's explicitly permitted. So now there are better customization points.

Given #1 and #2, it's rather unlikely existing code will break. Or at least, not enough for this to be a major problem. Code that used auto and register also "broke" in the past, but that minuscule amount of C++ code didn't stop progress.

share|improve this answer

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

Not really that radical. This change is based on this paper from Walter E. Brown. The paper goes into rationale rather deeply, but ultimately it boils down to this:

1. Specialization of function templates is rather poor as a customization point. Overloading and ADL are much better in that regard. There are other customization points discussed in the paper as well.


2. The standard library doesn't rely on this poor customization point too much already.


3. The wording change that's put into place actually permits adding entire declarations to namespace std (not just specializations) where it's explicitly permitted. So now there are better customization points.

Given #1 and #2, it's rather unlikely existing code will break. Or at least, not enough for this to be a major problem. Code that used auto and register also "broke" in the past, but that minuscule amount of C++ code didn't stop progress.

share|improve this answer

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

share|improve this answer

share|improve this answer

edited 45 mins ago

edited 45 mins ago

edited 45 mins ago

answered 50 mins ago

StoryTeller

85k12171237

answered 50 mins ago

StoryTeller

85k12171237

answered 50 mins ago

StoryTeller

85k12171237

85k12171237

add a comment | 

add a comment | 

up vote
4
down vote

As it stands now it definitly looks that way. The current draft states

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.

And it looks like the paper Thou Shalt Not Specialize std Function Templates! by Walter E. Brown is responsible for it. In it he details an number of reason why this should be changed such as

• Herb Sutter: “specializations don’t participate in overloading. [...] If you want to customize a function base template and want that customization to participate in overload resolution (or, to always be used in the case of exact match), make it a plain old function, not a specialization. And, if you do provide overloads, avoid also providing specializations.”


• David Abrahams: “it’s wrong to use function template specialization [because] it interacts in bad ways with overloads. [...] For example, if you specialize the regular std::swap for std::vector<mytype>&, your specialization won’t get chosen over the standard’s vector specific swap, because specializations aren’t considered during overload resolution.”


• Howard Hinnant: “this issue has been settled for a long time. . . . Disregard Dave’s expert opinion/answer in this area at your own peril.”


• Eric Niebler: “[because of] the decidedly wonky way C++ resolves function calls in templates. . . , [w]e make an unqualified call to swap in order to find an overload that might be defined in [...] associated namespaces[...] , and we do using std::swap so that, on the off-chance that there is no such overload, we find the default version defined in the std namespace.”


• High Integrity C++ Coding Standard: “Overload resolution does not take into account explicit specializations of function templates. Only after overload resolution has chosen a function template will any explicit specializations be considered.”

share|improve this answer

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

add a comment | 

up vote
4
down vote

As it stands now it definitly looks that way. The current draft states

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.

And it looks like the paper Thou Shalt Not Specialize std Function Templates! by Walter E. Brown is responsible for it. In it he details an number of reason why this should be changed such as

• Herb Sutter: “specializations don’t participate in overloading. [...] If you want to customize a function base template and want that customization to participate in overload resolution (or, to always be used in the case of exact match), make it a plain old function, not a specialization. And, if you do provide overloads, avoid also providing specializations.”


• David Abrahams: “it’s wrong to use function template specialization [because] it interacts in bad ways with overloads. [...] For example, if you specialize the regular std::swap for std::vector<mytype>&, your specialization won’t get chosen over the standard’s vector specific swap, because specializations aren’t considered during overload resolution.”


• Howard Hinnant: “this issue has been settled for a long time. . . . Disregard Dave’s expert opinion/answer in this area at your own peril.”


• Eric Niebler: “[because of] the decidedly wonky way C++ resolves function calls in templates. . . , [w]e make an unqualified call to swap in order to find an overload that might be defined in [...] associated namespaces[...] , and we do using std::swap so that, on the off-chance that there is no such overload, we find the default version defined in the std namespace.”


• High Integrity C++ Coding Standard: “Overload resolution does not take into account explicit specializations of function templates. Only after overload resolution has chosen a function template will any explicit specializations be considered.”

share|improve this answer

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

add a comment | 

up vote
4
down vote

up vote
4
down vote

As it stands now it definitly looks that way. The current draft states

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.

And it looks like the paper Thou Shalt Not Specialize std Function Templates! by Walter E. Brown is responsible for it. In it he details an number of reason why this should be changed such as

• Herb Sutter: “specializations don’t participate in overloading. [...] If you want to customize a function base template and want that customization to participate in overload resolution (or, to always be used in the case of exact match), make it a plain old function, not a specialization. And, if you do provide overloads, avoid also providing specializations.”


• David Abrahams: “it’s wrong to use function template specialization [because] it interacts in bad ways with overloads. [...] For example, if you specialize the regular std::swap for std::vector<mytype>&, your specialization won’t get chosen over the standard’s vector specific swap, because specializations aren’t considered during overload resolution.”


• Howard Hinnant: “this issue has been settled for a long time. . . . Disregard Dave’s expert opinion/answer in this area at your own peril.”


• Eric Niebler: “[because of] the decidedly wonky way C++ resolves function calls in templates. . . , [w]e make an unqualified call to swap in order to find an overload that might be defined in [...] associated namespaces[...] , and we do using std::swap so that, on the off-chance that there is no such overload, we find the default version defined in the std namespace.”


• High Integrity C++ Coding Standard: “Overload resolution does not take into account explicit specializations of function templates. Only after overload resolution has chosen a function template will any explicit specializations be considered.”

share|improve this answer

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

As it stands now it definitly looks that way. The current draft states

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.

And it looks like the paper Thou Shalt Not Specialize std Function Templates! by Walter E. Brown is responsible for it. In it he details an number of reason why this should be changed such as

• Herb Sutter: “specializations don’t participate in overloading. [...] If you want to customize a function base template and want that customization to participate in overload resolution (or, to always be used in the case of exact match), make it a plain old function, not a specialization. And, if you do provide overloads, avoid also providing specializations.”


• David Abrahams: “it’s wrong to use function template specialization [because] it interacts in bad ways with overloads. [...] For example, if you specialize the regular std::swap for std::vector<mytype>&, your specialization won’t get chosen over the standard’s vector specific swap, because specializations aren’t considered during overload resolution.”


• Howard Hinnant: “this issue has been settled for a long time. . . . Disregard Dave’s expert opinion/answer in this area at your own peril.”


• Eric Niebler: “[because of] the decidedly wonky way C++ resolves function calls in templates. . . , [w]e make an unqualified call to swap in order to find an overload that might be defined in [...] associated namespaces[...] , and we do using std::swap so that, on the off-chance that there is no such overload, we find the default version defined in the std namespace.”


• High Integrity C++ Coding Standard: “Overload resolution does not take into account explicit specializations of function templates. Only after overload resolution has chosen a function template will any explicit specializations be considered.”

share|improve this answer

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

share|improve this answer

share|improve this answer

edited 39 mins ago

edited 39 mins ago

edited 39 mins ago

answered 45 mins ago

NathanOliver

78.3k15106161

answered 45 mins ago

NathanOliver

78.3k15106161

answered 45 mins ago

NathanOliver

78.3k15106161

78.3k15106161

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52760580%2fwill-specialization-of-std-function-templates-for-user-defined-types-be-no-lon%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email