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

I don't know much about source filtering, and perhaps Filter::Util::Call does some whitespace munging, but does this regexp forbid sub declarations from being indented?

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

[download]
toby döt ink

Replies are listed 'Best First'.
Re^2: RFC: Inline::Blocks or inline as a keyword?
by shmem (Chancellor) on Aug 01, 2018 at 15:11 UTC

    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'
[reply]
[d/l]

      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