We’re making more changes!
Do the core developers ever sleep? Nope! We keep making Perl 6 better 24/7!
Not more than 24 hours ago, you may have read Upgrade Information for Changes Due to IO Grant Work. All of that is still happening.
However, it turned out that I, (Zoffix), had an incomplete understanding of how changes in 6.d language will play along with 6.c stuff. My original assumption was we could remove or change existing methods, but that assumption was incorrect. Pretty much the only sane way to incompatibly change a method in an object in 6.d is to add a new method with a different name.
Since I rather us not have, e.g.
.child-but-secure, for the next decade, we have a bit of an in-flight course correction:
ORIGINAL PLAN was to minimize incompatibilities with existing 6.c language code; leave everything potentially-breaking for 6.d
NEW PLAN is to right away add everything that does NOT break 6.c-errata specification, into 6.c language; leave everything else for 6.d. Note that current 6.c-errata specification for IO is sparse (the reason IO grant is running in the first place), so there’s lots of wiggle room to make most of the changes in 6.c.
I (Zoffix) still hope to cram all the changes into 2017.04 release. Whether that’s overly optimistic, given the time constraints… we’ll find out on April 17th. If anything doesn’t make it into 2017.04, all of it definitely will be in 2017.05.
Along with the original list in first Upgrade Information Notice, the following changes may affect your code. I’m excluding any non-conflicting changes.
IO::Path.abspathis being made private. Use
IO::Path.absoluteinstead; it provides the same functionality + lets you optionally provide a different CWD as well.
- It was previously possible to use
IO::Path.childto create unresolvable paths or paths that are not the children of the invocant’s path (e.g.
.child: "../../"). This use now causes the method to
failinstead, any time the path cannot be determined to be the child of the invocant. This means the path will be fully resolved and the method will fail if it can’t resolve it. For original functionality, use the newly-added
- All IO routines now throw typed exception instead of
- We’re adding a generic version of
IO::CatHandle(name still subject to bikeshedding) which
is IO::Handle. The
IO::ArgFilesclass will be kept for compatibility, but it’ll be just an empty class that
is IO::CatHandle. Note that this may modify what methods are available in
IO::ArgFiles, however existing methods that aren’t horribly broken should not be affected.
- This likely does not affect any code, but FYI
combpreviously captured most args and sent them all to
IO::Handle.open. Now, only the arguments that make sense in read-only non-binary mode, namely
$nl-in, will be forwarded. The rest will be ignored.
IO::Path.is-absoluteon Windows returns
Trueif the path starts with a [back]slash (without any drive letters). There’s some chance this is to be changed to return
Falseinstead. This is the only change in direct conflict with 6.c language specification, which is why the current behaviour might be kept unchanged, unless it’s deemed incorrect.
Changes for 6.d language:
.slurp-restmethod is being renamed to just
.slurp, which will be added in 6.c language. In 6.d language,
.slurp-restwill be deprecated, to be removed in later language versions.
IO::Path.chdirwill be deprecated in 6.d language, to be removed in later language versions. It’s a misnomer, as it doesn’t change any dirs. It merely creates a new path. Its behaviour can be replaced with one or more of
.xmethods. Note that this does NOT affect `&chdir` and `&*chdir` subroutines.
- There’s some chance
IO::Spec::*classes will be deprecated in 6.d, to be removed in a later language version, because they’re internal-ish. We’ll first have a trial run with the proposed changes implemented in a module (to be named
FastIO). If the module offers a lot of benefits, there will be a discussion on how to make it the default implementation for core IO.
Help and More Info
If you need help or more information, please join our IRC channel and ask there. You can also contact the person performing this work via Twitter @zoffix or by talking to user
Zoffix in our dev IRC channel