I'm quoting Rafael slightly out of order! * Rafael Garcia-Suarez <rgs@consttype.org> [2014-07-24T16:06:11] > It's more syntactic sugar than new operator. That said, there are benefits > and drawback in the 2 approaches. I think you did a good job hitting the nail on the head with the same things I'd thought about this. (Plus eof(), which I had not considered!) > So what would be a pragma name ? secure::open ? open::nomagic ? I'm not too worried about the name yet. Of those two, I prefer 'open::nomagic' because "no magic" is a bit safer of a claim than "secure." :) And we'll want to be clear whether this is affecting "open" or "open when dealing with ARGV". Let's come back to it, though? I'm more concerned about whether syntax or a pragma will pay off better in the long run. > Con: The syntax is backward-compatible, so technically we don't *need* a new > pragma to enable it. <<>> optimises for less verbosity. > > Pro: However on one-liners without a pragma we lack a way to transform the > implicit while(<>) of -n or -p into a while(<<>>). I think Abigail was right to note that we have to be wary of spooky action at a distance. On the other hand, I think that what you've given us is much more useful as a fixed default than an optional new behavior. That is: in *most* circumstances, I think the behavior of <> given @ARGV of ("rm -rfv *|") is going to surprise. Sure, it's documented, but that's not always a good reason to expect people to have the right expectations. :) (Also documented: ARGV::readonly -- but does anybody use it?) So, anyway, there are three reasons to want syntax for this: * there's no question about what "kind" of <> is active * no pragma/feature is needed to make it available * you can use both in one program (although I think this is a stretch! 😄 ) ...and some reasons to avoid it: * the programmer needs to remember to use the new form to avoid magic * it doesn't help with -n etc. Abigail notes that command-line-switch-generated code is often a place where we *do* want the magic. So do we want a way to get -n-but-with-nomagic-open? Ed and Rafael both seemed to like -P-and-so-on. To me, the most significant concern is probably the one about improving our defaults. I'm not sure I think this is the best solution, but let me know if you think it's clearly better or worse, or if it suggests anything else to you: * use feature 'magic_open_argv' * ...which goes into the default feature bundle, and old versions * ...but not the new version's bundle, so it's off by default on use 5.22 * ...and it's on in the while() code generated by -n * ...but we have -N and -P Although in my fantasy world, I'd make -n and -p *not* use magic open argv, I think we're liable to break too many familiar one-liners. I also think we'll better off making sure that the behavior of -p/-P is always *explicit*, rather than tied to -E/-e. Like I said: do you think this is better, worse, or just different? -- rjbsThread Previous | Thread Next