Hello Chapel community! When implementing the ability to rename a module when using it, we ended up re-examining how renaming a *symbol* in a module works when it comes to qualified naming (e.g. Foo.new_name). After discussion, we think the rules should be tweaked, but would like to get some feedback before making the change.
This email is to call your attention to the following Github issue to discuss the change: https://github.com/chapel-lang/chapel/issues/14738. The contents of that issue are also provided at the end of this message for convenience. Our intention is to begin implementing this change shortly. Looking forward to hearing your feedback! Lydia Duncan (on behalf of the Chapel team at HPE) Details: ------ Currently, you can only use the old name when performing qualified naming, and the new name for unqualified naming. For example: module L { var x: int = 42; } use L only x as y; writeln(x); // <-- Error today writeln(y); // L.x, works writeln(L.x); // L.x, works writeln(L.y); // <-- Error today, under discussion The thinking was that the module itself was not changing, so the rename isn't visible in that scope. However, when revisiting, we think that using the new name should be allowed. E.g. module L { var x: int = 42; } use L only x as y; writeln(L.y); // L.x, works The current proposal is to continue to allow qualified access with the old name as well - we do think it is a bit odd that the old name would still be available in this form, but we also think that it won't cause issues if it is still available. Forbidding access with the old name will have a greater potential to break backwards compatibility - however, it seems more likely for a user to *either* use qualified access *or* rename a symbol, rather than doing both for the same symbol, so doing so probably wouldn't be the end of the world. Otherwise, the only potential for breaking backwards compatibility happens if a symbol is renamed to the same name as a symbol that wasn't included, e.g. module L { var x: int; var y: int; } module User { use L only x as y; proc main() { writeln(L.y); // If this follows the renaming scheme, there is no way to // access the original L.y } } In this case, the original L.y will be inaccessible to the client code in any form. However, we think such cases are unlikely to be a problem in practice.
_______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
