in reply to Re: RFC: Inline::Blocks or inline as a keyword?
in thread RFC: Inline::Blocks or inline as a keyword?

Obviously, which is a bug arguably. But then, indented sub declarations are (within my coding standards) closures and such. I will use 

qr{^\s*inline\s+sub\s+(\w+)\s*(?:;|\{)}ms

[download]

if I can be convinced that this is a sensible default for inlineable subs.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^3: RFC: Inline::Blocks or inline as a keyword?
by tobyink (Canon) on Aug 01, 2018 at 15:27 UTC

    Indenting some sub definitions is useful for applying a lexical pragma like no warnings qw(redefine) but then again pragmata wouldn't survive inlining. (Though you could set pragma inside the sub.) I do also use them for grouping code occasionally, but the biggest reason to support indented sub definitions is:

    package Foo {
   sub bar {
      ...;
   }
}

    [download]
    toby döt ink
[reply]
[d/l]
[select]
      (...) but the biggest reason to support indented sub definitions is:

      Now that's convincing. Well erm... to do things right I'd need to check also what the current package is, for package NAME BLOCK definitions. Then, there could be a inline subroutine(LIST) or even inline subroutine LIST calling an inlineable subroutine imported from elsewhere. I could require B::Deparse and do a coderef2text in that case. Looks like the CAVEATS section needs to be much longer in the pod... or much more work to be done.

      But then, as I mentioned elsewhere in this thread, I'm not at all sure if this package is worth the effort.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]

In Section Meditations