Boolean Implication

Boolean implication A implies B simply means "if A is true, then B must be true". This implies (pun intended) that if A isn't true, then B can be anything. Thus:

False implies False -> True
False implies True  -> True
True  implies False -> False
True  implies True  -> True

This can also be read as (not A) or B - i.e. "either A is false, or B must be true".

Here's how I think about it:

if(A)
  return B;
else
  return True;

if A is true, then b is relevant and should be checked, otherwise, ignore B and return true.

I think I see where Serge is coming from, and I'll try to explain the difference. This is too long for a comment, so I'll post it as an answer.

Serge seems to be approaching this from the perspective of questioning whether or not the implication applies. This is somewhat like a scientist trying to determine the relationship between two events. Consider the following story:

A scientist visits four different countries on four different days. In each country she wants to determine if rain implies that people will use umbrellas. She generates the following truth table:

Did it rain?  Did people      Does rain => umbrellas?  Comment
              use umbrellas?  
No            No              ??                       It didn't rain, so I didn't get to observe
No            Yes             ??                       People were shielding themselves from the hot sun; I don't know what they would do in the rain
Yes           No              No                       Perhaps the local government banned umbrellas and nobody can use them. There is definitely no implication here.
Yes           Yes             ??                       Perhaps these people use umbrellas no matter what weather it is

In the above, the scientist doesn't know the relationship between rain and umbrellas and she is trying to determine what it is. Only on one of the days in one of the countries can she definitively say that implies is not the correct relationship.

Similarly, it seems that Serge is trying to test whether A=>B, and is only able to determine it in one case.

However, when we are evaluating boolean logic we know the relationship ahead of time, and want to test whether the relationship was adhered to. Another story:

A mother tells her son, "If you get dirty, take a bath" (dirty=>bath). On four separate days, when the mother comes home from work, she checks to see if the rule was followed. She generates the following truth table:

Get dirty?   Take a bath?   Follow rule?   Comment
No           No             Yes            Son didn't get dirty, so didn't need to take a bath. Give him a cookie.
No           Yes            Yes            Son didn't need to take a bath, but wanted to anyway. Extra clean! Give him a cookie.
Yes          No             No             Son didn't follow the rule. No cookie and no TV tonight.
Yes          Yes            Yes            He took a bath to clean up after getting dirty. Give him a cookie.

The mother has set the rule ahead of time. She knows what the relationship between dirt and baths are, and she wants to make sure that the rule is followed.

When we work with boolean logic, we are like the mother: we know the operators ahead of time, and we want to work with the statement in that form. Perhaps we want to transform the statement into a different form (as was the original question, he or she wanted to know if two statements are equivalent). In computer programming we often want to plug a set of variables into the statement and see if the entire statement evaluates to true or false.

It's not a matter of knowing whether implies applies - it wouldn't have been written there if it shouldn't be. Truth tables are not about determining whether a rule applies, they are about determining whether a rule was adhered to.