Difference between revisions of "DIP22"

From D Wiki
Jump to: navigation, search
(Version 2)
Line 16: Line 16:
 
|-
 
|-
 
|Last Modified:
 
|Last Modified:
|2013-02-04
+
|2013-12-20
 
|-
 
|-
 
|Author:
 
|Author:
Line 42: Line 42:
 
== Description ==
 
== Description ==
  
* All changes are same for both classes and modules: it breaks no code but leaves consistent approach.
+
* Private restricts the visibility of a symbol.
* Private symbol look-up with no overloads in action stays the same: error message about access.
+
 
* Overload resolution takes place after protection attribute questions are settled. '''private''' symbols do not take part in overload resolution.
+
  A private symbol will not interact with other modules.
* As privates are already non-virtual, override resolution does not need to change in this regard.
+
  In case look-up for a symbol fails the compiler might suggest private symbols similar to how spell checking work.
* All <code>__traits</code> still show private symbols. Those are advanced user tools and having this may be essential to library code. Same goes for access via .tupleof.
+
 
 +
* The least protected symbol determines the visibility for an overload set.
 +
 
 +
  After overload resolution an access check will be performed. Thereby overload resolution is independent of look-up origin.
 +
 
 +
* Meta programming tools like <code>__traits</code> and .tupleof can access private symbols.
 +
 
 +
  This is necessary for some generic code, e.g. serialization.
 +
 
 +
* All changes apply for modules as well as for classes.
 +
 
 +
  Protection has module granularity so looking up private
 +
  members of a base class from a different module follows
 +
  the same rules as accessing other private symbols from
 +
  a different module.
 +
  Additionally protected does allows access from derived classes
 +
  but not from other modules.
 +
 
 +
* Alias protection overrides the protection of the aliased symbol.
 +
 
 +
  A public alias to a private symbol makes the symbol
 +
  accessibly through the alias.
  
 
=== other protection attribute changes ===
 
=== other protection attribute changes ===
Line 65: Line 86:
  
 
== Walters concerns ==
 
== Walters concerns ==
[http://forum.dlang.org/thread/iakfgxjlfzrbxerxpria@forum.dlang.org?page=10#post-kb86il:241u9v:241:40digitalmars.com original comment]
+
[http://forum.dlang.org/post/kb86il$1u9v$1@digitalmars.com original comment]
  
 
1. ''what access means at module scope''
 
1. ''what access means at module scope''

Revision as of 20:24, 20 December 2013

Title: Private symbol visibility
DIP: 22
Version: 2
Status: Draft
Created: 2013-01-28
Last Modified: 2013-12-20
Author: Михаил Страшун (m.strashun gmail.com) (Dicebot)
Links: Access specifiers and visibility : data gathered before creating proposal

Changelog

Version 2

  • Proposals related to internal linkage separated to another DIP22.1
  • Added .tupleof to trait-like exclusions
  • Removed proposal to change an error message

Abstract

This proposal attempts to solve one of important issues with current protection attribute design: senseless name clashes between private and public symbols. So change of private related name resolution rules is proposed.

Rationale

private is an encapsulation tool. If it is not intended to be used by "outsiders", it should not interfere with them at all. It creates no new limitations and reduces amount of code breakage by changes in other modules.

Description

  • Private restricts the visibility of a symbol.
 A private symbol will not interact with other modules.
 In case look-up for a symbol fails the compiler might suggest private symbols similar to how spell checking work.
  • The least protected symbol determines the visibility for an overload set.
 After overload resolution an access check will be performed. Thereby overload resolution is independent of look-up origin.
  • Meta programming tools like __traits and .tupleof can access private symbols.
 This is necessary for some generic code, e.g. serialization.
  • All changes apply for modules as well as for classes.
 Protection has module granularity so looking up private
 members of a base class from a different module follows
 the same rules as accessing other private symbols from
 a different module.
 Additionally protected does allows access from derived classes
 but not from other modules.
  • Alias protection overrides the protection of the aliased symbol.
 A public alias to a private symbol makes the symbol
 accessibly through the alias.

other protection attribute changes

  • public stays the same
  • package matches private changes from the point of view of other packages
  • extern stays the same
  • protected matches private changes, descendants still treat protected symbols as public ones. It is a rare guest in idiomatic D code but does no harm and may be useful for transition from other languages.

other name resolution changes

  • UFCS functions should also take priority over private class functions when names conflict
  • alias this protection attribute overrides protection attribute of aliased symbol ( not transitive )

Possible code breakage and solutions

No previously valid code will become illegal in normal use cases, as this proposal is more permissive than current behavior. As __traits and .tupleof will still work for private as before, any library that relies on them should not break.

Walters concerns

original comment

1. what access means at module scope

"Does this symbol is ignored when doing symbol name look-up?". All protection attributes boil down to simple answer (Yes/No) depending on symbol origins and place look-up is made from. In example:

Symbol origin:               module a;
Look-up origin:              not module a;
Symbol protection attribute: private
Answer:                      No

2. at class scope

D minimal encapsulation unit is a module. Private class members are, technically, private module members and thus have the same behavior. Same for package and public. Protected is only special case that takes additional parameter into consideration.

3. at template mixin scope

No changes here. For templates look-up origin is definition module. For mixin templates - instantiation module. Other than that, usual rules apply.

4. backwards compatibility

See "Possible code breakage and solutions"

5. overloading at each scope level and the interactions with access

See "Description".

6. I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea

I have found no harm in keeping it. This will break code for sure and is irrelevant to this DIP topic.

7. there's also some debate about what "package" should mean

This is also irrelevant to this DIP. While there may be debates on meaning of package concept, meaning of package protection attribute is solid: encapsulation within set of modules belonging to same package, whatever they are.

Copyright

This document has been placed in the Public Domain.