> > Don't by confused by simplicity of examples, eg: > my @structs = ({ ... }, { ... }, ...); > my $var : const = [ @structs ]; > > > That copies the contents of @structs, after which the same rules apply. If > your point is that @structs uses { ... }, which is a reference, that > obviously should count as a const reference. That would be the same as > > my $var : const = [ { ... }, { ... }, ... ]; > > > If that is not what you are saying, I don't get the point. > > Oh, I missed your idea was to always do deep copy. That may work in few use cases, though it may be unnecessary expensive. Though still doesn't use case "for me data are read-only, for everyone else data are read-only / write-once". Thinking about it, there are multiple modes: - const ... value cannot be modified, never - read-only ... value is read-only in current context, though it can modified in another context - read-write ... value can be changed Another names to look: Postgresql functions - IMMUTABLE, STABLE, VOLATILE To me topic seems to be much more complex than simple idea, I'd like to suggest, if moving to RFC (imho should be) then it should contain also test cases covering many scenarios. One more to add, how it should behave? my $fh : const = *STDOUT; open STDOUT, q (>), q (foo.out); say $fh q (FOO); BranoThread Previous | Thread Next