On Tuesday, 11 February 2014 at 00:31:32 UTC, Walter Bright wrote:
> 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.

Oh, this was not related to package.d (it is a new thing and can't have established guidelines) - more of a general statement. For example, you have been arguing in PR to keep `lwr` and `upr` identifiers while quick grep shows that there is not a single place in Phobos which uses such naming scheme in public API. Such things are not related to any architectural choices - those are personal preferences and thus is less important than existing style guidelines by definition.

On 2/11/2014 5:30 AM, Dicebot wrote:
> For example, you have
> been arguing in PR to keep `lwr` and `upr` identifiers while quick grep shows
> that there is not a single place in Phobos which uses such naming scheme in
> public API.


grep -i -r lwr *.d
std\traits.d:        alias G Lwr;
std\traits.d:            enum ok = functionLinkage!Upr == functionLinkage!Lwr;
std\traits.d:            enum ok = variadicFunctionStyle!Upr == variadicFunctionStyle!Lwr;
std\traits.d:            // Note the order of arguments.  The convertion order Lwr -> Upr is
std\traits.d:            // correct since Upr should be semantically 'narrower' than Lwr.
std\traits.d:            enum ok = isStorageClassImplicitlyConvertible!(Lwr, Upr);
std\traits.d:            enum lwrAtts = functionAttributes!Lwr;
std\traits.d:                (  (uprAtts & wantExact)   == (lwrAtts & wantExact)) &&
std\traits.d:                (  (uprAtts & FA.pure_   ) >= (lwrAtts & FA.pure_  )) &&
std\traits.d:                (  (uprAtts & FA.nothrow_) >= (lwrAtts & FA.nothrow_)) &&
std\traits.d:                (!!(uprAtts & safety    )  >= !!(lwrAtts & safety   )) ;
std\traits.d:            enum ok = is(ReturnType!Upr : ReturnType!Lwr);
std\traits.d:            alias ParameterTypeTuple!Lwr LwrParams;
std\traits.d:            alias ParameterStorageClassTuple!Lwr LwrPSTCs;
std\traits.d:                    enum lwrStc = LwrPSTCs[i];
std\traits.d:                        ((uprStc & wantExact )  == (lwrStc & wantExact )) &&
std\traits.d:                        ((uprStc & STC.scope_)  >= (lwrStc & STC.scope_)) &&
std\traits.d:            static if (UprParams.length == LwrParams.length)
std\traits.d:                enum ok = is(UprParams == LwrParams) && checkNext!(0).ok;
std\typetuple.d: * type tuple. TL[$(I lwr) .. $(I upr)] returns a new type

On Wednesday, 12 February 2014 at 18:50:24 UTC, Walter Bright wrote:
> grep -i -r lwr *.d
> std\traits.d:        alias G Lwr;
> std\traits.d:            enum ok = functionLinkage!Upr == functionLinkage!Lwr;
> std\traits.d:            enum ok = variadicFunctionStyle!Upr == variadicFunctionStyle!Lwr;
> std\traits.d:            // Note the order of arguments.  The convertion order Lwr -> Upr is
> std\traits.d:            // correct since Upr should be semantically 'narrower' than Lwr.
> std\traits.d:            enum ok = isStorageClassImplicitlyConvertible!(Lwr, Upr);
> std\traits.d:            enum lwrAtts = functionAttributes!Lwr;
> std\traits.d:                (  (uprAtts & wantExact)   == (lwrAtts & wantExact)) &&
> std\traits.d:                (  (uprAtts & FA.pure_   ) >= (lwrAtts & FA.pure_
>  )) &&
> std\traits.d:                (  (uprAtts & FA.nothrow_) >= (lwrAtts & FA.nothrow_)) &&
> std\traits.d:                (!!(uprAtts & safety    )  >= !!(lwrAtts & safety
>   )) ;
> std\traits.d:            enum ok = is(ReturnType!Upr : ReturnType!Lwr);
> std\traits.d:            alias ParameterTypeTuple!Lwr LwrParams;
> std\traits.d:            alias ParameterStorageClassTuple!Lwr LwrPSTCs;
> std\traits.d:                    enum lwrStc = LwrPSTCs[i];
> std\traits.d:                        ((uprStc & wantExact )  == (lwrStc & wantExact )) &&
> std\traits.d:                        ((uprStc & STC.scope_)  >= (lwrStc & STC.scope_)) &&
> std\traits.d:            static if (UprParams.length == LwrParams.length)
> std\traits.d:                enum ok = is(UprParams == LwrParams) && checkNext!(0).ok;
> std\typetuple.d: * type tuple. TL[$(I lwr) .. $(I upr)] returns a new type

Exactly - all those places are internals of few very old templates ;) Other than one part of documentation in typetuple, have not noticed it initially. It is not even comparable with grep results for "lower" and "upper". I'd expect those places in std.traits to be fixed too once someone will be working on that part of code.

On 2/12/2014 10:55 AM, Dicebot wrote:
> I'd expect those
> places in std.traits to be fixed too once someone will be working on that part
> of code.

Worrying about "lwr" vs "lower" is so way, way far down the list of what we should be paying attention to it is not even visible.

On Wednesday, 12 February 2014 at 21:01:26 UTC, Walter Bright wrote:
> On 2/12/2014 10:55 AM, Dicebot wrote:
>> I'd expect those
>> places in std.traits to be fixed too once someone will be working on that part
>> of code.
>
> Worrying about "lwr" vs "lower" is so way, way far down the list of what we should be paying attention to it is not even visible.

Wording and naming in public interfaces is very important, which I'm sure you agree with.

it wouldn't have stolen anyone's attention if you'd just changed it as soon as it was mentioned. It was already demonstrated that the full `lower`/`upper` is far more common in Phobos than the hardly used abbreviations, so what's the big deal?

On Wednesday, 12 February 2014 at 21:01:26 UTC, Walter Bright wrote:
> On 2/12/2014 10:55 AM, Dicebot wrote:
>> I'd expect those
>> places in std.traits to be fixed too once someone will be working on that part
>> of code.
>
> Worrying about "lwr" vs "lower" is so way, way far down the list of what we should be paying attention to it is not even visible.

How can one review something more important if you ignore even basic style comments?

On 2/12/14, 1:01 PM, Walter Bright wrote:
> On 2/12/2014 10:55 AM, Dicebot wrote:
>> I'd expect those
>> places in std.traits to be fixed too once someone will be working on
>> that part
>> of code.
>
> Worrying about "lwr" vs "lower" is so way, way far down the list of what
> we should be paying attention to it is not even visible.

If they're in the public interface of your pull request and a reviewer asked you to make the change, make the change. It's a sensible request and making the change is the one civilized reply. Not doing so and insisting it's irrelevant is wasting everybody's time to a much larger extent.

Andrei

On 2/12/2014 1:18 PM, Dicebot wrote:
> How can one review something more important if you ignore even basic style
> comments?

Disagreeing with it is not ignoring it.

Am Sun, 09 Feb 2014 12:36:36 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
> > It depends on what syntax you expect. I solved it this way:
> >
> > void fun(alias length)(void* sneaky = alloca(length));
> >
> > void foo()
> > {
> >     size_t myLength = 42;
> >     fun!myLength();
> > }
> 
> Huge template bloat in current frontend state - new instance of `fun` for every single new function it is used in.

Thanks for the hint! I'll keep that in mind when the function becomes larger.

-- 
Marco

I have created a small summary for this proposal based on existing comments : http://wiki.dlang.org/Std.buffer.scopebuffer

By this point I consider initial discussion finished and from now it is up to Walter to prepare his proposal to formal review for Phobos inclusion.

Walter, please write me an e-mail (public-at-dicebot-lv) when you find yourself ready to next step. There are some concerns left that you can find down the abovementioned link - for most of those it is up to your personal judgement if anything needs to be changed about it.

However there is a single mandatory condition that needs to be met before I can start formal review thread - documentation. All Phobos proposals must have pre-generated documentation hosted somewhere and available for quick inspection of reviewers. DDOC also should cover all module details - not only plain function descriptions but also function parameters and return types.