Implicit type conversion: Difference between revisions
Content added Content deleted
(Added Go) |
SqrtNegInf (talk | contribs) (Added Perl example) |
||
Line 687: | Line 687: | ||
There are no user-defined types and hence no implicit conversion on them. |
There are no user-defined types and hence no implicit conversion on them. |
||
=={{header|Perl}}== |
|||
Perl is the original DWIM language, implicit type conversion is the default mode of operation. Perl does not have static types; the concept of distinct integers/strings/floats is not present. Instead, operators defines how the operands will behave. An operator that requires a string coerces its operand into a string, an operator that requires an integer coerces its operand into an integer, and so forth. |
|||
<lang perl>print 1 + '2'; # 3 |
|||
print '1' + '2'; # 3 |
|||
print 1 . 1; # 11 |
|||
$a = 1; |
|||
$b = 2; |
|||
say "$a+$b"; # 1+2 |
|||
# Even if you intentionally jumble the expected roles of numbers and strings, thing just work out |
|||
say hex int( (2 . 0 x '2') ** substr 98.5, '2', '2' ) . 'beef'; # 1359599</lang> |
|||
On the other hand, since Perl gives you a lot of rope, you have to be careful what you do with it. The expression |
|||
<code>'x' + 1</code> will return the answer '1', silently glossing over the meaningless use of an alphabetic character in addition. |
|||
This is the reason that <code>use warnings</code> should be present in most all your Perl code. Enabling warnings will alert you that <tt>Argument "x" isn't numeric in addition</tt>. |
|||
=={{header|Perl 6}}== |
=={{header|Perl 6}}== |