10-Feb-2014 04:59, Walter Bright пишет:
> On 2/9/2014 12:43 PM, Dmitry Olshansky wrote:
>
>> 1. I guess there is a distinctive quality to a buffer (i.e. it's not
>> just any
>> output range). The current interface looks quite arbitrary - is 'pop'
>> required
>> for any buffer?
>
> No, pop isn't required.

Then some canonical picture of what *any* Buffer is would be nice. I'm having a bit of deja vu with this discussion :)

>> A trait like isBuffer is in order, to allow user code to target
>> any buffers including non-Phobos ones.
>
> I don't understand the point of this suggestion.

If buffer is just an output range and 'put' is enough to model it, then fine. But see also recent thread on output ranges:
http://forum.dlang.org/thread/atfdzzxutxnduavvzvww@forum.dlang.org#post-atfdzzxutxnduavvzvww:40forum.dlang.org

It could be useful to define a more broad interface as a superset of output ranges.

>> 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.
>
Okay.

-- 
Dmitry Olshansky

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

In general, proposal to standard library is a place where defining common rules (and conforming to them) has higher priority over any common sense.

On 2/10/2014 4:24 AM, Dicebot wrote:
> In general, proposal to standard library is a place where defining common rules
> (and conforming to them) has higher priority over any common sense.

I cannot agree with following rules to the point of throwing common sense out the window.

On Monday, 10 February 2014 at 19:31:50 UTC, Walter Bright wrote:
>
> I cannot agree with following rules to the point of throwing common sense out the window.

If following the rules requires throwing common sense out of the window, perhaps it's time to change the rules.

On Monday, 10 February 2014 at 19:36:40 UTC, Francesco Cattoglio wrote:
> On Monday, 10 February 2014 at 19:31:50 UTC, Walter Bright wrote:
>>
>> I cannot agree with following rules to the point of throwing common sense out the window.
>
> If following the rules requires throwing common sense out of the window, perhaps it's time to change the rules.

Exactly. And it should be done in a separate proposal and with own discussion. Which can possibly reveal that common senses differ a lot and thus is necessary.

I personally will vote "No" for any new proposal that looks obviously alien from existing Phobos code, despite it being possibly very useful and desired and backed by sound reasoning.

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

On Monday, 10 February 2014 at 22:42:30 UTC, Jonathan M Davis wrote:
> 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.

Prohibiting alternative is not "discouraging", it is prohibiting. Discouraging is providing both options and clearly stating which one is recommended. So far D has been a very permissive language in terms of user choice, it is strange to suddenly start making restrictions here.

On Monday, 10 February 2014 at 22:42:30 UTC, Jonathan M Davis wrote:
> 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 absolutely hate getting symbol conflicts when importing multiple Phobos modules, but I don't think importing an entire package as a module is all that unreasonable. That's basically what we're doing right now, as Phobos is so flat. Your example of importing all of std is a bit extreme, but if we can't even support reasonable cases, then either D's module system, its design, or both have failed in this regard. One of the worst things about the module system currently is the private symbol conflicts, and fixing that would go a long way to allowing some real modularity in Phobos, as well as splitting up the different packages and factoring out any common functionality into privately-imported modules.

On 2/10/2014 11:46 AM, Dicebot wrote:
> I personally will vote "No" for any new proposal that looks obviously alien from
> existing Phobos code, despite it being possibly very useful and desired and
> backed by sound reasoning.

1. There are many, many package folders in phobos/druntime that do not have a package.d.

2. package.d can always be added. But it cannot be subtracted. Hence, it is best not to add it "just because", it needs more compelling arguments.

On 2/10/2014 2:45 PM, Dicebot wrote:
> Prohibiting alternative is not "discouraging", it is prohibiting. Discouraging
> is providing both options and clearly stating which one is recommended. So far D
> has been a very permissive language in terms of user choice, it is strange to
> suddenly start making restrictions here.

Often more than one way to do something in Phobos is tolerated for backwards compatibility reasons, not because it is a good idea on its own.

One old case comes to mind, where the author of a module wanted to provide both an OOP interface and a free function interface to the same functionality, in the name of "user choice". To me, this is giving some false illusion of flexibility, when in fact it is merely clutter and bloat.