# typeprivate
Create **typeprivate** access control level
Proposal: SE-NNNN
Author: [Gonçalo Alvarez](https://github.com/goncaloalvarez), [Álvaro Monteiro](https://github.com/amsmonteiro)
Status: **Proposed**
## Introduction
Access control modifiers are one of the cornerstones of Swift programming practices. Furthermore, proper usage of access control levels makes ground for proper API communication and clarity. They should be handled with great care. As a developer, one should dodge the path of massifying files with code whose responsible entity is the **Type** owning the file's real estate. Extensions do help in scoping the code and creating private contexts for better code structruing and readability. Extensions placed on another file should be able to access private members of such Type whenever they are **typeprivate**.
## Motivation
Excellence in software engineering is both achieved and backed by clear API communication. Access control levels are surely one of the driving forces for developers to communicate a clear and accurate API, granting access to a type's members or, on the other hand, hiding its details.
Thus, as a developer, it is good practice to create extensions for *protocol compliance*, *private methods*, *public methods*, and code with a very clear and related responsability within the Type it belongs to.
It is also good common practice to extend a Type's behaviour on separate files, either out of respect for context, or simply to improve code readability by reducing the size of the source file.
However, this raises an issue on accessing members of the *Reference Types* or *Value Types* whose access control modifier is more restrictive than *internal*, thus making it impossible to access or modify a *fileprivate* (and *private*) member on an extension placed other than within the source file for the Type in question. In fact, we believe there's too big a gap between this access control modifier and the one that follows in order of restrictiveness *fileprivate*.
Also, we believe that having the scope of a member limited by file scope does does fall short in fitting a language design purpose as, in out opinion, a file is a compiler related construct which could, in turn, be replaced somewhere in time, thus leaving the “fileprivate” access member orphaned.
**Case one**
This file has been truncated. show original