I can think of one place where people may be accidentally using this, and that is in import arguments to packages that also turn on 'strict' and 'warnings' for you. use Foo xxx, yyy, -foo; If you use strict and warnings before that then it will fail. However if that turns on strict and warnings like Moose and many other packages these days then it will work fine, and do what you expect (stringify the barewords). I am not making a judgement call on weather people SHOULD or SHOULD NOT do this. However I have seen it done, and discovered it when I realized I had accidentally been doing it in a few places. -Chad On Mon, Nov 23, 2015 at 11:57 AM, Lukas Mai <plokinom@gmail.com> wrote: > Am 23.11.2015 um 20:49 schrieb bulk88 via RT: > >> On Mon Nov 23 06:53:30 2015, ed wrote: >> >>> Yes, by 'barewords' I meant to say the treatment of unquoted >>> identifiers as strings, in cases where "use strict 'subs'" would give >>> an error. That is not the case for STDERR. >>> >>> Barewords will give a warning "clash with future reserved word", but >>> not if they have characters outside [a-z]. >>> >>> My question is first, whether anyone is still using this feature (I >>> have never come across code that uses it outside of golfing and >>> poetry, but I accept that different programmers have different >>> styles), and if the answer to the first question is "no", whether it >>> might be time to officially deprecate this feature. >>> >> >> https://metacpan.org/release/BULKDD/Acme-Win32-PEPM-0.02 uses them to >> pack .pm files. I've attached a sample packed .pm. >> >> > How much of that magic is fixed bytes? Because if it's just two bytes > ('MZ'), you can work around it with 'MZ() if 0;' or similar. No barewords! > > -- > Lukas Mai <plokinom@gmail.com> >Thread Previous | Thread Next