Phobos for Review: std.buffer.scopebuffer

[Jonathan M Davis]

On Monday, February 10, 2014 12:24:24 Dicebot wrote:
> On Monday, 10 February 2014 at 00:59:00 UTC, Walter Bright wrote:
> >> 2. May need buffer.package.d to import all common buffers
> >> (there is only one
> >> now, but with time...).
> > 
> > I do not like the idea of "kitchen sink" importing. The
> > package.d thing was designed so that we can split up the
> > existing kitchen sink modules without breaking user code.
> 
> It may be discouraged but in the end it is up to user to decide.
> I think all packages in Phobos must mandatory provide package.d

That would be _encouraging_ the use of importing whole packages at once, which 
I don't think that we're looking to do. If some folks want to do that with 
their own projects, fine, but the feature was introduced specifically in order 
to split of larger modules into packages, not to treat packages as modules. 
And on top of that, as has come a number of times previously when this sort of 
thing has been discussed, Phobos was not designed with the idea that you would 
import entire packages at once, and it could cause some entertaining symbol 
conflicts, which people would then complain about if we tried to support 
importing Phobos packages in general. Also, even if there weren't any 
conflicts now, we'd have to worry about additional conflicts every time that 
we added a symbol to Phobos. At the extreme, if std had a package.d file that 
imported _everything_ so that you could just import std; and have all of 
Phobos, then adding any symbol to any module in all of Phobos where there was 
another symbol with that same name in another, unrelated module would then 
break existing code.

I'm with Walter on this one. We shouldn't be adding any package.d files to 
Phobos except when splitting up existing modules. And even then, down the 
line, we might want to consider deprecating the imports in the package.d files 
that we introduce when splitting up modules so that existing code moves 
towards importing the new modules directly. But at minimum, we don't want to 
be introducing package.d files for existing packages. That's just asking for 
trouble.

- Jonathan M Davis