Data encapsulation in Swift - encapsulation

Question

I've read the entire Swift book, and watched all the WWDC videos (all of which I heartily recommend). One thing I'm worried about is data encapsulation.
Consider the following (entirely contrived) example:
class Stack<T>
{
var items : T[] = []
func push( newItem: T ) {
items.insert( newItem, atIndex: 0 )
}
func pop() -> T? {
if items.count == 0 {
return nil;
}
return items.removeAtIndex( 0 );
}
}
This class implements a stack, and implements it using an Array. Problem is, items (like all properties in Swift) is public, so nothing is preventing anyone from directly accessing (or even mutating) it separate from the public API. As a curmudgeonly old C++ guy, this makes me very grumpy.
I see people bemoaning the lack of access modifiers, and while I agree they would directly address the issue (and I hear rumors that they might be implemented Soon (TM) ), I wonder what some strategies for data hiding would be in their absence.
Have I missed something, or is this simply an omission in the language?

Answer 1

It's simply missing at the moment. Greg Parker has explicitly stated (in this dev forums thread) that visibility modifiers are coming.
Given that there aren't headers, the standard Objective-C tricks won't work, and I can't think of another trick to limit visibility that doesn't involve lots of bending over backwards. Since the language feature has been promised I'm not sure it's worth any big investment.
On the bright side since this feature is in flux, now is a great time to file a radar and influence how it turns out.

Answer 2

Updated answer for future reference.
From Apple's documentation:
Access Levels
Swift provides three different access levels for
entities within your code. These access levels are relative to the
source file in which an entity is defined, and also relative to the
module that source file belongs to.
Public access enables entities to
be used within any source file from their defining module, and also in
a source file from another module that imports the defining module.
You typically use public access when specifying the public interface
to a framework.
Internal access enables entities to be used within any
source file from their defining module, but not in any source file
outside of that module. You typically use internal access when
defining an app’s or a framework’s internal structure.
Private access
restricts the use of an entity to its own defining source file. Use
private access to hide the implementation details of a specific piece
of functionality. Public access is the highest (least restrictive)
access level and private access is the lowest (or most restrictive)
access level.

Answer 3

As a matter of fact I was delighted Swift finally adopted static typing so conforming to the theory for code with optimal OO properties, still the fall of the headers breaks the very meniang of Object Orienting programming, namely encapsulation. A way out would be like for Eiffel to automaticaly extract the headers but without specifying which are the public interfaces and which the private ones, it would be wortheless. I am really lambasted at this move of Apple's.