On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
> Also, inferring everything is quite
> expensive and we want D to compile fast.

Doesn't the compiler have to do that anyway?
I'd expect a proper compiler to check if my code is actually what
I claim it is. It's quite easy to mark something as e.g. nogc in
the first version and later on add code with allocations.

> Otherwise if you like D, then try to
>> improve it from the inside, writing dmd/Phobos/druntime pull requests,
>> instead of doing it from the outside.
>
> I'd never have my PR's pulled.
>
> I'm also not as interested in language development as it might appear.
> I'm interested in writing code and getting work done, and minimising
> friction.
> I'm interested in more efficient ways to get my work done, and also
> opportunities to write more efficient code, but that doesn't mean I
> want to stop doing my work and instead work on HOW I do my work.
>
>
>>> I find myself in a very awkward situation where I'm too far
>>> in... I can't go back to C++,
>>
>>
>> Have you taken a look at Rust?
>
> Yeah, it's just too weird for me to find realistic. It also more
> rigidly asserts it's opinions on you, which are in many cases, not
> optimal. Rust typically shows a performance disadvantage, which I care
> about.
> Perhaps more importantly, for practical reasons, I can't ever imagine
> convincing a studio of hundreds of programmers to switch to rust. C++
> programmers can learn D by osmosis, but staff retraining burden to
> move to Rust seems completely unrealistic to me.

You're a vital alternative voice, please try to stick with us. The interest your talk and presence generated for D was huge and the games industry should be a major target for D. I also suspect Andrei is doing a major project at the moment which is making him uncharacteristically harsh in his responses, from his POV he's doing something massive to help D while the community has gone into a negative mode.

I'm surprised at the lack of importance insufficient control over ref seems to be given, though my understanding is pretty basic. It feels a little similar to inlining.

It might be an effective argument to give bearophile some of the problematic code and see what his idiomatic D version looks like and if what you're after is elegantly achievable. Clunky code would seem like a stronger argument at this point after many words have been exchanged. I think people are not really aware of the issues and if they believe the things are truly achievable with the language as it stands they can demonstrate it, with benchmarks etc.

On Tuesday, 30 September 2014 at 09:13:02 UTC, ixid wrote:
>> Otherwise if you like D, then try to
>>> improve it from the inside, writing dmd/Phobos/druntime pull requests,
>>> instead of doing it from the outside.
>>
>> I'd never have my PR's pulled.
>>
>> I'm also not as interested in language development as it might appear.
>> I'm interested in writing code and getting work done, and minimising
>> friction.
>> I'm interested in more efficient ways to get my work done, and also
>> opportunities to write more efficient code, but that doesn't mean I
>> want to stop doing my work and instead work on HOW I do my work.
>>
>>
>>>> I find myself in a very awkward situation where I'm too far
>>>> in... I can't go back to C++,
>>>
>>>
>>> Have you taken a look at Rust?
>>
>> Yeah, it's just too weird for me to find realistic. It also more
>> rigidly asserts it's opinions on you, which are in many cases, not
>> optimal. Rust typically shows a performance disadvantage, which I care
>> about.
>> Perhaps more importantly, for practical reasons, I can't ever imagine
>> convincing a studio of hundreds of programmers to switch to rust. C++
>> programmers can learn D by osmosis, but staff retraining burden to
>> move to Rust seems completely unrealistic to me.
>
> You're a vital alternative voice, please try to stick with us. The interest your talk and presence generated for D was huge and the games industry should be a major target for D. I also suspect Andrei is doing a major project at the moment which is making him uncharacteristically harsh in his responses, from his POV he's doing something massive to help D while the community has gone into a negative mode.

+10 <3

Pardon the pandering, but I actually see Andrei Walter and you as
making up the trinity of idealism, codegen pragmatism and
industry use respectively.

On Tuesday, 30 September 2014 at 00:03:40 UTC, Manu via Digitalmars-d wrote:
> I've affected all of the change that I am capable of, and I need to
> decide if I'm happy with D as is, or not, rather than maintain my
> ambient frustration that it's sitting at 99%, with the last 1%
> unattainable to me unless I fork the language for my own use :/

Try to add some rudimentary support for ref in the compiler yourself?

It is not a big semantic change (it is only pointers after all).

On 9/30/14, 2:13 AM, ixid wrote:
> from his POV he's doing something massive to help D while the community
> has gone into a negative mode.

Indeed that's an accurate characterization of my POV. -- Andrei

ixid:

> It might be an effective argument to give bearophile some of the problematic code and see what his idiomatic D version looks like and if what you're after is elegantly achievable.

Manu is quite more expert than me in the kind of code he writes. So what you propose is just going to show my limits/ignorance...

Bye,
bearophile

On Tuesday, 30 September 2014 at 11:45:37 UTC, Ola Fosheim Grøstad wrote:
>
> (it is only pointers after all).

Semi-tangential to this discussion, but this bit hits on something I've been thinking for a little while... ref is, at its core, trying to be a non-nullable pointer.  And I get the strong sense that it's failing at it.

-Wyatt

On Tuesday, 30 September 2014 at 13:08:57 UTC, Wyatt wrote:
> Semi-tangential to this discussion, but this bit hits on something I've been thinking for a little while... ref is, at its core, trying to be a non-nullable pointer.  And I get the strong sense that it's failing at it.

That's a very perceptive observation. :)

So you also get a sense that D could have non-nullable reference semantics for a ref-type?

And possibly extend it to be assignable as a const-mutable-reference (pointer) using a dedicated operator or using the more ugly "&" notation or a cast?

In Simula you had two assignment operators that made the the ref/value issue visually distinct.

a :- b;  //a points to b
x := y;  // x is assigned value of y

It is analogue to the "==" vs "is" distinction that many languages make. I think it makes sense to have that visual distinction. Makes code easier to browse.

On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via Digitalmars-d wrote:
> On 30 September 2014 16:06, Daniel N via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr wrote:
>>>
>>> On 09/29/2014 04:43 AM, Walter Bright wrote:
>>>>
>>>>
>>>> You're right that tuples in D cannot contain storage classes
>>>
>>>
>>> void foo(ref int x){}
>>> alias p=ParameterTypeTuple!foo;
>>> pragma(msg, p); // (ref int)
>>>
>>> (But this does not help.)
>>
>>
>> Well, only if you are sufficiently desperate. ;)
>>
>> struct S(alias T)
>> {
>>   void f(ParameterTypeTuple!T p)
>>   {
>>   }
>> }
>>
>> S!((ref int x, int y){}) s;
>
> I have actually thought of that ;) ... but I tend to think that only D
> users present on this forum are likely to make sense of that code, and
> why.

Perhaps this might help you a little:

http://code.dlang.org/packages/storageclassutils

sure, it's not as elegant as one would like, but it at least provides some basic utility.

On Tuesday, 30 September 2014 at 13:47:22 UTC, John Colvin wrote:
> On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via Digitalmars-d wrote:
>> On 30 September 2014 16:06, Daniel N via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr wrote:
>>>>
>>>> On 09/29/2014 04:43 AM, Walter Bright wrote:
>>>>>
>>>>>
>>>>> You're right that tuples in D cannot contain storage classes
>>>>
>>>>
>>>> void foo(ref int x){}
>>>> alias p=ParameterTypeTuple!foo;
>>>> pragma(msg, p); // (ref int)
>>>>
>>>> (But this does not help.)
>>>
>>>
>>> Well, only if you are sufficiently desperate. ;)
>>>
>>> struct S(alias T)
>>> {
>>>  void f(ParameterTypeTuple!T p)
>>>  {
>>>  }
>>> }
>>>
>>> S!((ref int x, int y){}) s;
>>
>> I have actually thought of that ;) ... but I tend to think that only D
>> users present on this forum are likely to make sense of that code, and
>> why.
>
> Perhaps this might help you a little:
>
> http://code.dlang.org/packages/storageclassutils
>
> sure, it's not as elegant as one would like, but it at least provides some basic utility.

Also, I just wrote it in a few hours after seeing your post, so obviously there are plenty of improvements that could be made.