On 18/10/16 07:34, Walter Bright wrote:
> You've gotten user defined attributes in the language (and very
> undemocratically, I might add!), Win64 support, VC++ symbolic debug
> info, a number of improvements to C++ class support, SIMD support, SIMD
> intrinsics, pragma inline, yeah, we never listen to you :-)
>
> You've been a large influence over D, and a very positive one.

I take issue with that statement. Not with Manu being a positive influence, of course, but with the legitimacy of telling someone what it is they should care about. Andrei is known to have done it as well (with statements such as "choose your battles and fight them well").

You cannot tell someone volunteering his time to not care about some thing. This is simply not how you create a heterogeneous community.

This is also a very bad strategy. If you accept the premise that it is possible for something to be flawed, but for both you and Andrei to not understand it is so (i.e. - the premise that both you and Andrei are human with human failing), any system in which you can control what gets discussed is a system that guarantees that this flaw will never get fixed.

I understand that certain topics seem to crop up again and again, and the discussions around them seem circular. There are ways to prevent that without shutting down people.

For example, taking a page from one of my pet peeves, if anyone bringing up integer promotion is not dealt with "yeah, we've discussed that and it's pointless to bring it up", but instead is shown the counter examples that halted the discussion the previous time, I believe several things will happen:

1. People will feel they are listened to. The decision will seem (but, I believe, also actually be) less arbitrary.
2. People will know where to focus their attention if they wish for this to change
3. Someone may actually find a solution.

You cannot argue with "this will never happen". You can argue with "this doesn't work because of X".

Shachar

On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:
> Better:
>
>    void f(ref Vector v);
>    void f(Vector v) { f(v); }
>
>    f(Vector(10,20,30));

Suitable enough for simple functions. But beyond that becomes maintenance hell.

For example:

void func2( ref const( Vector ) v1, ref const( Vector ) v2 );

Requires the following permutations:

void func2( const( Vector ) v1, ref const( Vector ) v2 ) { func2( v1, v2 ); }
void func2( ref const( Vector ) v1, const( Vector ) v2 ) { func2( v1, v2 ); }
void func2( const( Vector ) v1, const( Vector ) v2 ) { func2( v1, v2 ); }

For example:

void func3( ref const( Vector ) v1, ref const( Vector ) v2, ref const( Vector ) v3 );

Requires the following permutations:

void func3( const( Vector ) v1, const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( ref const( Vector ) v1, const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( ref const( Vector ) v1, ref const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( ref const( Vector ) v1, const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( const( Vector ) v1, ref const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( const( Vector ) v1, const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); }
void func3( const( Vector ) v1, ref const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); }

Did I miss one in that block? I think I missed one. Thus my point. If you were to provide something that Just Works(TM) out of the box for all possible creation states of your ref variables, you need to permute on all the ref parameters in your function. Which is either a process prone to human error; or in automated binding code, more things to parse at compile time resulting in slower compile times.

On Thursday, 20 October 2016 at 10:23:40 UTC, Ethan Watson wrote:
> On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:
>> Better:
>>
>>    void f(ref Vector v);
>>    void f(Vector v) { f(v); }
>>
>>    f(Vector(10,20,30));
>
> Suitable enough for simple functions. But beyond that becomes maintenance hell.
>
> For example:
>
> void func2( ref const( Vector ) v1, ref const( Vector ) v2 );

----
auto invoke(F, V...)(F f, V vs)
{
	return f(vs);
}

invoke(&func2, Vector(1, 2, 3), Vector(4, 5, 6));
----

One function to rule them all. :o

On 10/18/2016 02:40 AM, David Soria Parra wrote:
> On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:
>> Thanks, David. Hope you're doing well! I was curious about one thing - is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of improvement is in many ways more difficult than reviewing a well-argued DIP.
>>
>> I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido.
> 
> PEPs (sorry I totally misspelled that before) have a editors who are responsible for scrutinizing the PEP before and as far as I understand are the ones who can request review from the BDFL (Guido), who either takes the final decision or delegates it (e.g. in cases were someone is better suited in the area to make the call). Editors are trusted core committers that are sponsoring an improvement.
> 
> The process is outline in great detail at https://www.python.org/dev/peps/pep-0001/#pep-workflow and I recommend reading it. Maybe we get some good ideas on how to create a process that is scalable and results in the high quality standards we have but are more suited towards the smaller community we are.
> 
> We should start small and see how we find something that Walter, you and contributors feel good about and improve from there:
> 
> might suit our needs.

But this is pretty much the process we have right now! Differences I can see:

- currently I am the only person acting as a preliminary "editor"
- I don't hold right to reject anything, only to request more
information/improvements
- it features decision delegates to someone else but BDFL is certain cases
- transition between various stages is more formally defined

I doubt anyone complaining about existing DIP process would have a slightest chance to get a PEP of similar quality and style accepted as a draft.

On 10/17/2016 05:44 AM, deadalnix wrote:
> On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:
>> Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected.
>>
> 
> I spent fuck 4;5 years on that thing. Don't come at me saying I'm not interested in polishing it. I'm not interested in wasting my time. That's entirely different.

You did a rather terrible job if that DIP document was a result of 4.5 year effort. And that is the most polite thing I can say about such statement.

Let's make it clear - https://github.com/dlang/DIPs/pull/16 featured a great idea and that was the ONLY positive bit about it. Structure and clarity of explanations are plain terrible. It looks more like throwing in the proposal with "now you go figure it out" attitude than a formal document.

You never took requests to make it more clear to the heart, making only trivial tweaks. Clear signs of how DIP is lacking in clarity (the very irrelevant comments and long pause times) are now interpreted as process issue, but in fact those are your personal issue as DIP author.

If you think those demands are not acceptable - new process was not designed for you and I am happy I have not wasted more of my time trying to get it into shape.

On 10/20/2016 06:23 AM, Ethan Watson wrote:
> On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:
>> Better:
>>
>>    void f(ref Vector v);
>>    void f(Vector v) { f(v); }
>>
>>    f(Vector(10,20,30));
>
> Suitable enough for simple functions. But beyond that becomes
> maintenance hell.

I agree this workaround has a combinatorial problem.

Again, lest this got lost: I think a solid DIP addressing the problem would have a good chance to get traction. We are in a better place than we used to with handling ref, and also with the general understanding of the general matter and how it was problematic for C++.

I'm thinking a DIP would work well around the following lines:

* Explain the problem with well-motivated examples.

* Related work and workarounds, most notably "auto ref" in templates. Explain how "auto ref" is insufficient. Explain how workarounds are insufficient.

* Propose a semantics that would address the problem. By far the preferred way is by means of a lowering to existing language. The obvious lowering is to have the compiler introduce "auto" variables prior to the call, as follows:

In the call fun(e1, e2), if e1 and e2 are rvalues and fun specifies it accepts an rvalue by reference for both parameters, the lowering is:

fun(e1, e2)

=>

{ auto __1 = e1, __2 = e2; return fun(__1, __2); }()

There are potential issues with fun returning ref, which the DIP should address.

* Propose an annotation to indicate the function allows rvalues. What comes to mind:

(a) Expand the use of "auto ref" to nontemplates. The common objection to this is we'd have the same syntax express subtly different semantics (for templates there are two distinct functions generated, and inside the template it is possible to distinguish between the two). The DIP should address this objection.

(b) Use an attribute, e.g. void fun(@rvalue ref Vector);

* Discuss how the annotation affects function signature and mangling (not sure but probably there should be no effect).

* Sketch the changes to the language definitions.



Thanks,

Andrei

On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:
> On 10/20/2016 06:23 AM, Ethan Watson wrote:
>> Suitable enough for simple functions. But beyond that becomes
>> maintenance hell.
>
> I agree this workaround has a combinatorial problem.

Yes, Ethan made a good point I hadn't thought of. And any DIP on the matter should cover this point (else it will come up again). These sorts of things are why a DIP should be done - to collect all these points in one place.

On 10/20/2016 04:57 PM, Walter Bright wrote:
> On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:
>> On 10/20/2016 06:23 AM, Ethan Watson wrote:
>>> Suitable enough for simple functions. But beyond that becomes
>>> maintenance hell.
>>
>> I agree this workaround has a combinatorial problem.
>
> Yes, Ethan made a good point I hadn't thought of. And any DIP on the
> matter should cover this point (else it will come up again). These sorts
> of things are why a DIP should be done - to collect all these points in
> one place.

The combinatorial explosion was one core motivation for C++ rvalue references. I think the authors of the would-be DIP would do good to be conversant with that proposal. -- Andrei

On 10/20/2016 2:53 PM, Andrei Alexandrescu wrote:
> The combinatorial explosion was one core motivation for C++ rvalue references. I
> think the authors of the would-be DIP would do good to be conversant with that
> proposal. -- Andrei


"However, as the number of free parameters grows (as in bind and function), this solution quickly grows impractical. The number of overloads required increases exponentially with the number of parameters (2N where N is the number of parameters)."

Proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html

Spec changes:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html

On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis wrote:
> The transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly, you wouldn't bother with const ref, but it could be an object that contains a range, and because you can't normally get a tail-const range from a const range (aside from dynamic arrays), it can become quite difficult to actually iterate over the range. e.g.
>
> auto foo(ref const(Bar) bar)
> {
>     auto range = bar.getSomeRange();
>     ...
> }
>

Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)?

> Because getSomeRange would have to be const (or inout) in order to be called, the return type is going to have be const if there are any indirections in it. And if it's const, and it's a range, it's useless.
>
> If this were C++, const wouldn't be transitive, so it would be trivial to get an iterator or range which wasn't const and did not violate const or attempt to work around it in any way and thus could be iterated. But in D, const is far too restrictive for that to work.
>
> This is the kind of problem that quickly makes you start wondering whether it's even worth trying to use const in D at all.
>
> - Jonathan M Davis