Exploring Language Support for Immutability Michael Coblenz, Joshua Sunshine, Sam Weber, Jonathan Aldrich, Brad Myers Forrest Shull Carnegie Mellon University Software Engineering Institute 5000 Forbes Avenue 4500 Fifth Avenue Pittsburgh, PA, USA Pittsburgh, PA, USA {mcoblenz, sunshine, [email protected], aldrich, bam}@cs.cmu.edu [email protected] ABSTRACT security flaws. For example, Bloch devoted a section of Programming languages can restrict state change by pre- his book E↵ective Java [6] to minimizing mutability. He venting it entirely (immutability) or by restricting which cited the following benefits of immutability: simple state clients may modify state (read-only restrictions). The ben- management; thread-safety; and safe and efficient sharing. efits of immutability and read-only restrictions in software Oracle’s Secure Coding Guidelines for Java SE [31] states structures have been long-argued by practicing software en- that immutability aids security. Microsoft’s Framework De- gineers, researchers, and programming language designers. sign Guidelines recommends against defining mutable value However, there are many proposals for language mecha- types in part because they are passed by copy, and program- nisms for restricting state change, with a remarkable diver- mers might write code that modifies copies but should in- sity of techniques and goals, and there is little empirical stead modify the original structure [29]. Some programming data regarding what practicing software engineers want in languages, such as Rust [30], take these recommendations their tools and what would benefit them. We systematized into account by carefully managing mutability. The func- the large collection of techniques used by programming lan- tional programming language community is particularly con- guages to help programmers prevent undesired changes in cerned with state management, producing languages such as state. We interviewed expert software engineers to discover Haskell, which segregates code that manipulates state from their expectations and requirements, and found that im- code that does not. Proponents of functional languages ar- portant requirements, such as expressing immutability con- gue that avoiding mutable data structures facilitates rea- straints, were not reflected in features available in the lan- soning about behavior of programs because one can reason guages participants used. The interview results informed equationally about behavior rather than needing to know our design of a new language extension for specifying im- about the global or even local program state [1]. mutability in Java. Through an iterative, participatory de- There are questions, however, about what immutability sign process, we created a tool that reflects requirements should mean and how to express immutability in program- from both our interviews and the research literature. ming languages, as evidenced by the myriad of di↵erent kinds of support that tools provide and the lack of empiri- cal data to justify specific design choices. Some languages CCS Concepts support programmer-provided specifications of immutability Software and its engineering Language features; (expressing that certain data structures cannot be changed) Software• development techniques; ! or read-only restriction (expressing that certain references cannot be used to change a data structure). For example, final in Java can express that a particular field cannot be Keywords reassigned to refer to a di↵erent object, but the contents of Programming language design, Programming language us- the referenced object may still change. Furthermore, there ability, Immutability, Mutability, Programmer productivity, is no way to express class-level immutability directly. Empirical studies of programmers In C++, const data can still refer to non-const data, which can then be changed. Furthermore, const provides no guarantees regarding other references to the same object. 1. INTRODUCTION This means that in addition to not providing the expected Many designers of APIs and programming languages rec- benefits of immutability to programmers, such as thread ommend using immutability in order to prevent bugs and safety and simple state management, these annotations also do not provide the guarantees that would be needed for the Permission to make digital or hard copies of all or part of this work for personal or many compiler optimizations that require all of an object’s classroom use is granted without fee provided that copies are not made or distributed behavior to be guaranteed to be fixed. for profit or commercial advantage and that copies bear this notice and the full cita- tion on the first page. Copyrights for components of this work owned by others than This paper makes the following contributions: ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- After reviewing the existing literature and imple- publish, to post on servers or to redistribute to lists, requires prior specific permission • mented systems in this area, we develop a classification and/or a fee. Request permissions from [email protected]. system for mutability restrictions in programming lan- ICSE ’16, May 14-22, 2016, Austin, TX, USA guages ( 2), show where some existing systems fit in c 2016 ACM. ISBN 978-1-4503-3900-1/16/05. $15.00 § this classification ( 3), and discuss possible usability DOI: http://dx.doi.org/10.1145/2884781.2884798 § implications of existing design choices ( 4). ensure that aliases to objects do not escape their owners, We interviewed eight expert software engineers§ to find ensuring representation containment and defining a notion • out how practitioners feel about existing language fea- of abstract state, since the abstract state ( 2.5) of an ob- tures and tools, and what their perceived needs are. ject includes only data it owns. Ownership§ is also useful We show that existing programming language features for ensuring thread safety of mutable structures by ensuring and research tools do not adequately address the issues that locks are acquired in a correct order according to the encountered by practitioners. We extract design rec- ownership structure before accessing objects [7]. ommendations from the results of our interviews ( 5). IGJ is a Java extension that adds annotations speci-§ 2.2 Scope • fying immutability and read-only restrictions [42]. We Object-based restrictions apply to a particular object. describe the design of IGJ-T, an extension to IGJ that Class-based restrictions apply to all of a class’s instances. enforces transitive immutability, which addresses prob- For example, final is object-based: it only applies to a lems that our interview participants described. We it- specific reference and there is no way of specifying that all eratively evaluated IGJ-T with three pilot users and references to instances of a particular class are final. refined our study based on the feedback ( 6). Class restrictions, while commonly either only supported § as syntactic sugar for object restrictions (e.g. IGJ) or unsup- 2. OVERVIEW OF CONCEPTS ported entirely, are frequently needed in practice according In existing literature, the wide variety of approaches and to our interview participants. By necessity, many program- mers who want class immutability must improvise ( 3.2). subtle di↵erences among the di↵erent goals can make it dif- § ficult to understand which problems each system addresses. Thus, it is important to distinguish among the many dif- 2.3 Transitivity ferent meanings given to the term immutability and related Transitive restrictions pertain to all objects reachable concepts. In this section, we will give an overview of the var- from a given object, including objects captured by closures ious mechanisms and issues. Up to this point, we have been or methods. Non-transitive restrictions pertain only to the using the term immutability informally; here we synthesize immediate fields in a given object. definitions from existing literature to form a definition that Non-transitive restrictions provide weak guarantees be- will be used in the rest of the paper. A summary of the cause they say little about the behavior of the abstraction concepts appears in Table 2. that the object’s interface provides. For example, if a list We use object here to mean any kind of state, such as a C object is non-transitively immutable, then the number of struct or a functional language ref cell. State is data that is items in the list is fixed, and the list always refers to the stored in memory. As an abbreviation, we will use function same objects, but the contents of those objects can still be to refer to both functions and methods. changed. A function that needed to know that a list of inte- gers only contained positive integers would need to re-check 2.1 Type of Restriction all elements after every possible opportunity for mutation of Immutability restricts modification through all references list elements. However, in order to ensure that an object is to a given object (see 2.5 for exceptions). In contrast, read- immutable, one must verify that all objects in the transitive only restrictions disallow§ modification through read-only ref- closure of references from that object are immutable. erences to a given object, but not necessarily through all ref- Though the assignability and read-only features provided erences. The distinction between read-only restrictions and in many popularly-used languages are non-transitive, includ- immutability is critical to the correctness of programs. For ing