[std-proposals] Enforce explicit casting on assignment and return type ‘bool’

[Johnny Shaw]

Recently I’ve noticed some interpretations of the following standards
resulting in removing of compiler warnings around implicit conversions to a
‘bool’ type:



1) C++14 §4.12/1 “A zero value, null pointer value, or null member pointer
value is converted to false; any other value is converted to true. For
direct-initialization (8.5), a prvalue of type std::nullptr_t can be
converted to a prvalue of type bool; the resulting value is false.”
2) C99 and C11 §6.3.1.2/1 “When any scalar value is converted to _Bool, the
result is 0 if the value compares equal to 0; otherwise, the result is 1.”



Specifically, the VS1017 compiler has removed the following warning
completely:

https://msdn.microsoft.com/en-us/library/b6801kcy.aspx



Over correspondence with Microsoft I’ve noticed it my be due to direct
interpretation of standards. See:

https://developercommunity.visualstudio.com/content/problem/346302/vs2017-158-c-fails-to-warn-when-forcing-int-to-boo.html

https://developercommunity.visualstudio.com/content/problem/349342/visual-studio-2017-158-allows-implicit-conversion.html



This is moving the bar backward a bit, resulting in unintended bugs being
overlooked that would have previously been caught by the compiler.



While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates mistakes.
Enforcing a standard that requires explicit conversion to bool, at very
least for a return value, will eliminate possible coding errors. The
following are some mundane examples and could be overlooked with given more
complex code:


bool TestFunc(int a)
{
return a;
}

bool TestFuncNotOver100(int a)
{
if (a > 100)
{
return a;
}
return true;
}

bool TestPointerForNull(void* pvX)
{
if (nullptr != pvX)
{
return false;
}
return pvX;
}




At very least requiring a check against a matching type by boolean
operation, for example:

bool TestFunc(int a)
{
return (0 == a);
}




Or for assignment:


int a = 1;
bool bValue = (0 == a);




Moreover, requiring an explicit cast:


bool TestFunc(int a)
{
return static_cast<bool>(a);
}

[Thiago Macieira]

Post by Johnny Shaw
While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates mistakes.
Enforcing a standard that requires explicit conversion to bool, at very
least for a return value, will eliminate possible coding errors.

And break a lot of existing code. Because of that, you need to provide strong
justification why this should be adopted.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Johnny Shaw]

Fair point, I'll rephrase then.

*Define a standard for compiler warnings with respect to requiring explicit
conversions to bool.*

The use case here is type safety. One of the valuable things I appreciate
about C++ is the ability to clearly define your intent and ensure type safe
use.

The fact that Microsoft removing this compiler warning has *already *broken
some code out there (seen first hand). Therefor, it does feel like a step
backward - maybe I'm being naive. Yes, enforcing more standards around
compiler warnings might break some code out there from *compiling*. But, is
that a bad thing - wouldn't it be better to highlight when the developer is
making a mistake. And fix a bug at compile. Rather than deal with it at run
time.

In general, more standards around compiler warnings would benefit the
language in the long-run. Especially in the type-safety space, even if
those are optional warnings.

[Andrew Sandoval]

Post by Johnny Shaw

Post by Johnny Shaw
While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates

mistakes.

Post by Johnny Shaw
Enforcing a standard that requires explicit conversion to bool, at very
least for a return value, will eliminate possible coding errors.

And break a lot of existing code. Because of that, you need to provide strong
justification why this should be adopted.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Thiago,

How does a compiler *warning *break any existing code?

Instead it is going to highlight poorly written code and common mistakes.

Keep in mind that things like Intellisense, though very helpful, also help
to introduce additional mistakes. It is a very common thing that the IDE
supplies or completes the wrong variable, and the developer in a hurry
misses it, and then they return something that is NOT a bool for a function
that should return a bool. A compile-time warning would save time, money,
and embarrassment.

Anything we do to improve the compiler's ability to catch mistakes makes
the language better. And one of the selling points of C++ is type safety,
which is frankly fairly badly broken with regards to bool conversions. It
is bad enough that I'm ready to start requiring (in reviews) code to use
enum class instead of bool, even if there are only two choices in the enum
-- because the compiler requires a static_cast to convert and enum class to
any other type, even if you specify a type (as in: enum class MyEnum :
unsigned int).

-Andrew Sandoval

[Ville Voutilainen]

Post by Andrew Sandoval

Post by Thiago Macieira

Post by Johnny Shaw
While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates mistakes.
Enforcing a standard that requires explicit conversion to bool, at very
least for a return value, will eliminate possible coding errors.

And break a lot of existing code. Because of that, you need to provide strong
justification why this should be adopted.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Thiago,
How does a compiler warning break any existing code?

Very easily, this happens on every major compiler release. A compiler
adds a new warning, enables it under warning flags
that users already use, and -Werror does the rest.

Post by Andrew Sandoval
Instead it is going to highlight poorly written code and common mistakes.

And break valid code that has nothing wrong in it.

Post by Andrew Sandoval
Keep in mind that things like Intellisense, though very helpful, also help to introduce additional mistakes. It is a very common thing that the IDE supplies or completes the wrong variable, and the developer in a hurry misses it, and then they return something that is NOT a bool for a function that should return a bool. A compile-time warning would save time, money, and embarrassment.
Anything we do to improve the compiler's ability to catch mistakes makes the language better. And one of the selling points of C++ is type safety, which is frankly fairly badly broken with regards to bool conversions. It is bad enough that I'm ready to start requiring (in reviews) code to use enum class instead of bool, even if there are only two choices in the enum -- because the compiler requires a static_cast to convert and enum class to any other type, even if you specify a type (as in: enum class MyEnum : unsigned int).

Great, then you don't need a language change.

[Andrew Sandoval]

On Sun, Oct 7, 2018 at 10:05 AM Ville Voutilainen <

Post by Johnny Shaw

Post by Andrew Sandoval

Post by Thiago Macieira

Post by Johnny Shaw
While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates

mistakes.

Post by Andrew Sandoval

Post by Thiago Macieira

Post by Johnny Shaw
Enforcing a standard that requires explicit conversion to bool, at

very

Post by Andrew Sandoval

Post by Thiago Macieira

Post by Johnny Shaw
least for a return value, will eliminate possible coding errors.

And break a lot of existing code. Because of that, you need to provide

strong

Post by Andrew Sandoval

Post by Thiago Macieira
justification why this should be adopted.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Thiago,
How does a compiler warning break any existing code?

Very easily, this happens on every major compiler release. A compiler
adds a new warning, enables it under warning flags
that users already use, and -Werror does the rest.
Ville, of course that is true -- we just saw things break in Visual Studio

2017 due to changes around the register and inline keywords. And frankly,
I'm not trying to pick a battle with you or anyone else here -- I know you
contribute greatly to C++, but let's be honest... A *warning* doesn't
break the code. A *warning* doesn't "break" anything -- it just warns.
And in so doing, it provides us opportunities to re-examine old code to see
if the warning is warrants changes that might fix real bugs or
vulnerabilities.

Anyway, there is no point arguing the semantics of the word "break". I
really wasn't intended that, just backing up what has been said on the
topic, because I have seen where a warning on bool conversion would have
saved time and therefore money. And I appreciate very much Thaigo's
response to my questions.

Post by Johnny Shaw

Post by Andrew Sandoval
Instead it is going to highlight poorly written code and common mistakes.

And break valid code that has nothing wrong in it.

Post by Andrew Sandoval
Keep in mind that things like Intellisense, though very helpful, also

help to introduce additional mistakes. It is a very common thing that the
IDE supplies or completes the wrong variable, and the developer in a hurry
misses it, and then they return something that is NOT a bool for a function
that should return a bool. A compile-time warning would save time, money,
and embarrassment.

Post by Andrew Sandoval
Anything we do to improve the compiler's ability to catch mistakes makes

the language better. And one of the selling points of C++ is type safety,
which is frankly fairly badly broken with regards to bool conversions. It
is bad enough that I'm ready to start requiring (in reviews) code to use
enum class instead of bool, even if there are only two choices in the enum
-- because the compiler requires a static_cast to convert and enum class to
unsigned int).
Great, then you don't need a language change.

Sure, there are alternatives, and I can make rules around the code base I
am responsible for, but that is kind of heartless to everyone else who has
to suffer from common mistakes that we could have the compilers catch.
Besides, I think the reason Johnny brought this up was as a "proposal" for
discussion, not a mandate to you or anyone else. If you can find fault
with the suggestion, or argue that mistakes could not be prevented by
either recommending a warning, or requiring a cast (e.g. static_cast) on
bool conversions, then please do so. You know some of the more intricate
details of the language that may elude the rest of us, and your insights
would be far more valuable than curt responses. If I seemed to deserve
that response, then you have my apology for provoking it.

Thanks,
Andrew Sandoval

[Dilip Ranganathan]

You know some of the more intricate details of the language that may elude
the rest of us, and your insights would be far more valuable than curt
responses. If I seemed to deserve that response, then you have my apology
for provoking it.

Clearly you haven't been at the business end of Mr. Nicol Bolas'
suggestions yet :-)
Speaking of which, I haven't seen him posting all that much lately.

[Hyman Rosen]

Post by Dilip Ranganathan
Clearly you haven't been at the business end of Mr. Nicol Bolas'
suggestions yet :-)
Speaking of which, I haven't seen him posting all that much lately.

He's busy plotting the conquest of Ravnica :-)
<
https://shop.tcgplayer.com/magic/guilds-of-ravnica-mythic-edition/nicol-bolas-planeswalker

[Hyman Rosen]

On Sun, Oct 7, 2018 at 1:05 PM Ville Voutilainen <

Post by Ville Voutilainen

Post by Andrew Sandoval
How does a compiler warning break any existing code?

Very easily, this happens on every major compiler release. A compiler
adds a new warning, enables it under warning flags
that users already use, and -Werror does the rest.

If people build using -Werror then they are not programming in C++, but in
some
subset language arbitrarily determined by their implementor. Why should a
group
devoted to Standard C++ care about people who program in a different
language?

[Thiago Macieira]

Post by Hyman Rosen
On Sun, Oct 7, 2018 at 1:05 PM Ville Voutilainen <

Post by Ville Voutilainen

Post by Andrew Sandoval
How does a compiler warning break any existing code?

Very easily, this happens on every major compiler release. A compiler
adds a new warning, enables it under warning flags
that users already use, and -Werror does the rest.

If people build using -Werror then they are not programming in C++, but in
some
subset language arbitrarily determined by their implementor. Why should a
group
devoted to Standard C++ care about people who program in a different
language?

By the same token, warnings need not be discussed in this mailing list because
they are not part of the C++ standard. They are QoI at best.

Anyway, I recommend Andrew and other interested parties suggest the creation
of a Study Group to propose and maintain a Standing Document that focuses on
warnings compiler implementers ought to have, those that have a proven track
record of improving code quality and those new ones that have the potential to
prevent new bugs. This SG may also come up with a list of constructs that
should be more than just warnings and should be completely rejected, like the
case of deleting incomplete types we discussed last month.

And if I may make a suggestion: make sure every warning comes with one or more
solutions to suppress the warning that don't include compiler switches or
#pragmas. Examples:

1) && precedence over ||
if (a && b || c)
suggested:
if ((a && b) || c)

2) memcpy a non-trivially-copyable type
memcpy(&dst, &src, sizeof(*dst));
suggested:
memcpy(static_cast<void *>(&dst), static_cast(&src), sizeof(*dst));

3) cast to bool
return ptr;
suggested:
return bool(ptr);

4) signed integer overflow
// alloc's value is known by propagation to be size + 1
if (size + count > alloc)
suggested:
????

etc.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Hyman Rosen]

Post by Thiago Macieira
By the same token, warnings need not be discussed in this mailing list because
they are not part of the C++ standard. They are QoI at best.

That's not true. I'm looking at N4741, and it mentions warnings in a
number of places:
[dcl.attr.fallthrough], [dcl.attr.unused], [dcl.attr.nodiscard],
[dcl.attr.noreturn]
They're all in notes and examples, but those are still part of the
standard, and they say
things like "implementations should issue a warning" and "warning ...
discouraged".

['Alisdair Meredith' via ISO C++ Standard - Future Proposals]

See my previous post on ‘explicit operator bool’, that would be useful for your implementation here, specifically avoiding the accidental operator==.

AlisdairM

Sent from my iPhone

Post by Thiago Macieira
By the same token, warnings need not be discussed in this mailing list because
they are not part of the C++ standard. They are QoI at best.

[dcl.attr.fallthrough], [dcl.attr.unused], [dcl.attr.nodiscard], [dcl.attr.noreturn]
They're all in notes and examples, but those are still part of the standard, and they say
things like "implementations should issue a warning" and "warning ... discouraged".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZcqvC4Len7ewSGr1cxVxaiknnU-mezQSYPmwGz4GsZiA%40mail.gmail.com.

['Alisdair Meredith' via ISO C++ Standard - Future Proposals]

Doh! Attached reply to wrong email in this thread.

Sent from my iPhone

Post by 'Alisdair Meredith' via ISO C++ Standard - Future Proposals
See my previous post on ‘explicit operator bool’, that would be useful for your implementation here, specifically avoiding the accidental operator==.
AlisdairM
Sent from my iPhone

Post by Thiago Macieira
By the same token, warnings need not be discussed in this mailing list because
they are not part of the C++ standard. They are QoI at best.

[dcl.attr.fallthrough], [dcl.attr.unused], [dcl.attr.nodiscard], [dcl.attr.noreturn]
They're all in notes and examples, but those are still part of the standard, and they say
things like "implementations should issue a warning" and "warning ... discouraged".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZcqvC4Len7ewSGr1cxVxaiknnU-mezQSYPmwGz4GsZiA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/E2DB90EB-4D96-49E6-8AD6-D235ADE418D1%40me.com.

[Thiago Macieira]

Post by Andrew Sandoval

Post by Johnny Shaw

Post by Johnny Shaw
While there is value in implicit conversion under some circumstances.
Explicit conversion clearly identifies the intent and eliminates

mistakes.

Post by Johnny Shaw
Enforcing a standard that requires explicit conversion to bool, at very
least for a return value, will eliminate possible coding errors.

And break a lot of existing code. Because of that, you need to provide strong
justification why this should be adopted.

Thiago,
How does a compiler *warning *break any existing code?

We've never dealt with warnings in this mailing list, since the standard
doesn't deal with them either. I missed the fact that the original email was
asking for warnings and assumed it was talking about syntax changes.

Post by Andrew Sandoval
Instead it is going to highlight poorly written code and common mistakes.

Nothing wrong with that in warnings. But warnings need to be sensible and I am
not sure this case counts as either poorly-written or a common mistake. Yes,
there may be instances of the cast being unintentional. What remains to be
seen is whether the ratio is high enough to justify annoying everyone else who
got it right with a warning.

Otherwise, it would go to the books as an annoyance to everywhere where it was
already right, like the GCC warning on
if (a && b || c)

Post by Andrew Sandoval
Keep in mind that things like Intellisense, though very helpful, also help
to introduce additional mistakes. It is a very common thing that the IDE
supplies or completes the wrong variable, and the developer in a hurry
misses it, and then they return something that is NOT a bool for a function
that should return a bool. A compile-time warning would save time, money,
and embarrassment.

And returning something that is not a bool in a function that returns bool is
often the exact thing that was intended. Some thing like:

bool isValid() { return size; }
or
bool isValid() { return ptr; }

A cast to bool or a double-bang could help with making it absolutely clear
that it was intended and not a mistake, but my point is that the code above is
already right. Adding a warning means annoying the developers who wrote that
code and quite often everyone using it.

Post by Andrew Sandoval
Anything we do to improve the compiler's ability to catch mistakes makes
the language better.

Not everything. This needs to be weighed against the side effects, whether
intentional or not.

Post by Andrew Sandoval
And one of the selling points of C++ is type safety,
which is frankly fairly badly broken with regards to bool conversions. It
is bad enough that I'm ready to start requiring (in reviews) code to use
enum class instead of bool, even if there are only two choices in the enum
-- because the compiler requires a static_cast to convert and enum class to
unsigned int).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[g***@gmail.com]

Post by Thiago Macieira
And returning something that is not a bool in a function that returns bool is
bool isValid() { return size; }
or
bool isValid() { return ptr; }
A cast to bool or a double-bang could help with making it absolutely clear
that it was intended and not a mistake, but my point is that the code above is
already right. Adding a warning means annoying the developers who wrote that
code and quite often everyone using it.

I think this kind of code should be warned on by default on all compilers
and I'd be happy if the Standard mandated that It generated warnings by
default.
If people want to write such code they should be forced to use some warning
disable switch for that case and wrestle with the non standard realities of
using that switch but by default I'd like all compilers to encourage better
code for the cases you have outlined here.

[Thiago Macieira]

Post by g***@gmail.com
I think this kind of code should be warned on by default on all compilers
and I'd be happy if the Standard mandated that It generated warnings by
default.
If people want to write such code they should be forced to use some warning
disable switch for that case and wrestle with the non standard realities of
using that switch but by default I'd like all compilers to encourage better
code for the cases you have outlined here.

That is not the standard.

But it could be a side document produced by a workgroup that specialises on
suggestions to compiler developers on what to warn to improve code quality.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[o***@join.cc]

Post by g***@gmail.com

Post by Thiago Macieira
And returning something that is not a bool in a function that returns bool is
bool isValid() { return size; }
or
bool isValid() { return ptr; }
A cast to bool or a double-bang could help with making it absolutely clear
that it was intended and not a mistake, but my point is that the code above is
already right. Adding a warning means annoying the developers who wrote that
code and quite often everyone using it.

I think this kind of code should be warned on by default on all compilers
and I'd be happy if the Standard mandated that It generated warnings by
default.
If people want to write such code they should be forced to use
some warning disable switch for that case and wrestle with the non standard
realities of using that switch but by default I'd like all compilers
to encourage better code for the cases you have outlined here.

Other people think this kind of code should NOT be warned on by default on
all compilers and would be unhappy if the Standard mandated so..

[Andrew Sandoval]

Post by o***@join.cc
Other people think this kind of code should NOT be warned on by default on
all compilers and would be unhappy if the Standard mandated so..
Olaf, can you elaborate on the reasons why this would be a problem for

"other people"? And is there any good reason why the Standard should not
make strong recommendations on warning -- or at least on optional warnings
and maybe why someone would choose to enable or disable them.

I can argue that the current automatic / implicit conversion violates type
safety. The only argument so far that I've seen for implicit conversion of
bool is because there is some existing code that would break if it
changed. I'm interested in knowing *if *I am being naive about this how
so, because I know perfectly well from past experiences that there is a
vast pool of knowledge here that we can learn from.

Thanks,
Andrew Sandoval

[Hyman Rosen]

Post by Andrew Sandoval
I can argue that the current automatic / implicit conversion violates type
safety.

Automatic type conversion is everywhere in C and C++.
That ship sailed decades ago.

The only argument so far that I've seen for implicit conversion of bool

Post by Andrew Sandoval
is because there is some existing code that would break if it changed.

You have missed the argument that conversion from non-zero to true
and zero to false is nearly always what people want.

[Johnny Shaw]

If I may diverge the conversation slightly. Say I wanted to enforce more
type safety myself using constructs available in the language. How would I
go about doing that? I don't think it's possible, maybe I'm just missing
something:

#include <iostream>

enum class Boolean : char
{
False,
True
};

class boolean_t
{
private:
Boolean m_bVal{ Boolean::False };

public:
boolean_t() = default;

boolean_t(Boolean bVal) : m_bVal(bVal)
{
}


boolean_t(const boolean_t& bCopy) : m_bVal(bCopy.m_bVal)
{
}

boolean_t(bool) = delete; // explicitly deleted construction from 'bool'

operator bool()
{
if (Boolean::False == m_bVal)
{
return false;
}
return true;
}


operator Boolean()
{
return m_bVal;
}


friend boolean_t operator==(int lVal, int rVal) // not possible, must
have at least one formal parameter of class type
{
if (lVal == rVal)
{
return Boolean::True;
}
return Boolean::False;
}
};


boolean_t Test(int x)
{
return (0 == x); // no constructor for 'boolean_t' by 'bool', no
matching operator== that returns 'boolean_t'
}


int main()
{
std::cout << (true == Test(100) ? "true" : "false");
return 0;
}

In the Test function the value is going to be implicitly case too a bool.
However, I've explicitly deleted the constructor for a 'boolean_t' from a
'bool'. Implementing one results in functional code, but does not enforce a
contact that a developer make a comparison against a matching type. For
example:

boolean_t(bool bVal) : m_bVal(true == bVal ? Boolean::True : Boolean::False
)
{
}

boolean_t Test(int x)
{
return (0 == x); // allows this
}

boolean_t Test(int x)
{
return x; // but also allows this, defeating the purpose
}

If I could do something like this:

friend boolean_t operator==(int lVal, int rVal)
{
if (lVal == rVal)
{
return Boolean::True;
}
return Boolean::False;
}

That would give me a means to enforce type safety around bool usage. Maybe
there is mechanism I'm not keen to.

[o***@gmail.com]

Post by Andrew Sandoval

Post by o***@join.cc
Other people think this kind of code should NOT be warned on by default
on all compilers and would be unhappy if the Standard mandated so..
Olaf, can you elaborate on the reasons why this would be a problem for

"other people"?

Most code using the constructs is simply correct.

Post by Andrew Sandoval
And is there any good reason why the Standard should not make strong
recommendations on warning -- or at least on optional warnings and maybe
why someone would choose to enable or disable them.

Yes, the committee has more important things to do. ;)

Post by Andrew Sandoval
I can argue that the current automatic / implicit conversion violates type
safety.

What part of type safety does it violate?

['Alisdair Meredith' via ISO C++ Standard - Future Proposals]

This is why explicit conversion operators were introduced in C++11, if they were already mentioned in this thread, then sorry, I missed them.

Once we have the ability to mark a conversion as explicit, then we are left with the question of how the language forms a conversion when one is needed, such as the predicate in an ‘if’. Is the language forming an explicit conversion to ‘bool’ in such contexts, or does it rely on an implicit conversion? This was a deliberate point of discussion in the language design for C++11, and the conclusion is that when the a language construct requires such a conversion, it is a ‘contextual’ conversion that has access to explicit conversions. That is deliberately intended, as it is idiomatic to be able to test smart pointers just like raw pointers, and that idiom must continue to be supported for raw pointers for compatibility with inline C functions (even if we were prepared to break a large amount of existing C++ code).

This solves the problem of implicit conversion when passing arguments, returning values, or initializing variables, and avoids introducing an insidious support for ‘operator==‘ that happens with implicit conversions.

This was deemed to be the sweet spot of convenience vs. accidental misuse, and was extended to integral types in general (e.g., for switch statements) in C++14.

If we were to revoke contextual conversions, we would go a long way towards what you are asking for, but I would expect significant objections from many customers deliberately using the existing features as intended.

AlisdairM

Sent from my iPhone

1) C++14 §4.12/1 “A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true. For direct-initialization (8.5), a prvalue of type std::nullptr_t can be converted to a prvalue of type bool; the resulting value is false.”
2) C99 and C11 §6.3.1.2/1 “When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.”
https://msdn.microsoft.com/en-us/library/b6801kcy.aspx
https://developercommunity.visualstudio.com/content/problem/346302/vs2017-158-c-fails-to-warn-when-forcing-int-to-boo.html
https://developercommunity.visualstudio.com/content/problem/349342/visual-studio-2017-158-allows-implicit-conversion.html
This is moving the bar backward a bit, resulting in unintended bugs being overlooked that would have previously been caught by the compiler.
bool TestFunc(int a)
{
return a;
}
bool TestFuncNotOver100(int a)
{
if (a > 100)
{
return a;
}
return true;
}
bool TestPointerForNull(void* pvX)
{
if (nullptr != pvX)
{
return false;
}
return pvX;
}
bool TestFunc(int a)
{
return (0 == a);
}
int a = 1;
bool bValue = (0 == a);
bool TestFunc(int a)
{
return static_cast<bool>(a);
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5df28d28-a2f4-47cd-9da7-49c91ed6d6f4%40isocpp.org.