in reply to Re: Use of uninitialized value in substr
in thread Use of uninitialized value in substr

I expect Perl to warn me when concatenating undef to a string.

This is not about " concatenating undef to a string.". Though even in your unrealistic example, you've explicitly chosen to do that--as dumb as it is--so why should you expect or want a warning. Yes, you could suppress it, but why should you have to for something that could not possibly by "by accident".

The real question is about making explicit undef semantically different from indirect undef; and therefore making it more powerful, and useful.

The consensus, to my surprise, is that isn't useful. I think that's at least a premature judgement, if not outright wrong, but I'm insufficiently enamoured with the notion to argue the case further. Which is why I made this 'testing of the waters' post, a SoPW rather than a meditation.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy
  • Comment on Re^2: Use of uninitialized value in substr

Replies are listed 'Best First'.
Re^3: Use of uninitialized value in substr
by ikegami (Patriarch) on May 03, 2010 at 16:12 UTC

    This is not about " concatenating undef to a string.".

    That's exactly what happens to the 4th arg of substr.

    Yes, you could suppress it, but why should you have to for something that could not possibly by "by accident".

    eh? Of course you can pass an undefined value to substr by accident.

    The real question is about making explicit undef semantically different from indirect undef

    ah! There wasn't even an allusion to this. It's not even an existing concept in Perl as far as anyone is concerned. (Yes, I'm aware there's an instance where literal undef is special in an obscure and unused usage of a builtin, but it's not info I keep in my mind.)

    No thanks for this feature. The following come to mind:

    • It's a solution in search of a problem
    • It adds magic to avoid clear, concise code.
    • It adds a whole new type of variable with high cost and low gains.
    • It adds inconsistencies to the warning system.
    • It adds inconsistencies to substr.

    It's not one of those cases where I can'tcan provide concrete explanation or example. It just reeks of trouble.

    Update: Spelled out some of the reasons.

[reply]
      That's exactly what happens to the 4th arg of substr.

      No it's not!. It replaces (a potentially null), part of the target string. That is not concatenation. Maybe a limitaion of your english?

      Of course you can pass an undefined value to substr by accident..

      Did I say you couldn't? What don't you understand about "explicit undef"?

      ah! There wasn't even an allusion to this..

      You think? Read again.

      It's not one of those cases where I can't provide concrete explanation or example. It just reeks of trouble..

      Ha! Do it! But you won't be getting counter-argument from me. Been down that road to many times and it is pointless.

      You always arrive at a conclusion and then set out to prove it, rather than examine the up & downsides and then reach a conclusion.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        It replaces (a potentially null), part of the target string. That is not concatenation.

        Replacing part of a string means concatenating the part that precedes the replacement with the replacement, and that with what follows the replacement.

        Did I say you couldn't?

        "why should you have to for something that could not possibly by "by accident""

        Read again.

        Done. Still don't see it. Not in the OP.

        Ha! Do it!

        Sorry, typo. I meant "It's not one of those cases where I can'tcan provide concrete ..."

        rather than examine the up & downsides and then reach a conclusion.

        Why do you bother commenting if you think I just make stuff up. You asked for our opinion, so I gave mine. I've already added five of my reasons to the post.

[reply]
          A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom