Re^2: 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'

Comment on Re^2: RFC: Inline::Blocks or inline as a keyword? Download Code

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]
Re^4: RFC: Inline::Blocks or inline as a keyword? by shmem (Chancellor) on Aug 01, 2018 at 22:58 UTC
(...) 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]


Pathologically Eclectic Rubbish Lister
	PerlMonks