Manu:

> Trouble for me is, I've invested so much time now.

If your think your choice was the wrong one, don't invest even more in something you think is wasted effort. 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 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?

Bye,
bearophile

On 30 September 2014 09:25, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 29 September 2014 at 08:02:45 UTC, Andrei Alexandrescu wrote:
>>
>> I understand. The short answer to this is D cannot do that and we cannot afford to change the language to make it do that.
>>
>> There are two longer answers.
>>
>
> I think this is because ref have several conflated meaning:
>   - "I want to mess up with the argument" (à la swap). This is the
> meaning it has right now.
>   - "Burrowing". Which is the same as previous behavior, except
> for classes and delegates, so the whole scope story, as they are
> natural "reference types".
>   - "Do not copy" aka const ref. This one is for performance
> reason. It doesn't really matter if a copy is made or not as the
> damn thing is const, but one want to avoid expensive copy when
> the thing passed down is fat.

I don't see ref that way at all. I see it so much simpler than that:
ref is a type of pointer. It's effectively T(immutable(*)).
It's uses are emergent from what it is; a good way to pass big things
around in argument lists, or share references to a single instance of
something.
It also offers an advantage due to the nature that the pointer is
immutable; you don't need the pointer syntax baggage (*, &) when
dealing with ref's, which is very convenient in user code.

I think all this 'meaning' is a mistake; all that does is confuse the
matter. You don't attribute such 'meaning' to a normal pointer, it's a
primitive type.
If it's defined by some conceptual rubbish, then when it's attempted
to be used in some situation that doesn't perfectly fit the conceptual
attribution, you find yourself in awkward logical situations with
weird edge cases.
If you just say "it's an immutable pointer, and follows value syntax
semantics for practical reasons", then it's very clear what it does.
It's also very clear what that means to the ABI, and relationships
with other languages.

A similar mistake from C is where 'int' doesn't mean '32bits', it means some conceptual nonsense that seemed like a good idea at the time, but the result is, you don't really know what 'int' is, and everyone reinvents it so it works reliably (typedef int32 something).


> Each of them have their own set of cases where you want and do not want ref.

I agree, cases where ref should be used are non-trivial. It may be a result of external factors, some user logic, or explicit request from user code. The fact that it lives outside the type system makes that whole reality very awkward indeed.

On Tuesday, 30 September 2014 at 00:33:08 UTC, Manu via
Digitalmars-d wrote:
> I don't see ref that way at all. I see it so much simpler than that:
> ref is a type of pointer. It's effectively T(immutable(*)).
> It's uses are emergent from what it is; a good way to pass big things
> around in argument lists, or share references to a single instance of
> something.

"I don't agree with your diagnostic. I'm suing ref conforming of
cases 2 and 3 of your diagnostic".

That sounds like a self defeating statement.

On 30 September 2014 10:44, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 30 September 2014 at 00:33:08 UTC, Manu via Digitalmars-d wrote:
>>
>> I don't see ref that way at all. I see it so much simpler than that:
>> ref is a type of pointer. It's effectively T(immutable(*)).
>> It's uses are emergent from what it is; a good way to pass big things
>> around in argument lists, or share references to a single instance of
>> something.
>
>
> "I don't agree with your diagnostic. I'm suing ref conforming of cases 2 and 3 of your diagnostic".
>
> That sounds like a self defeating statement.

... huh?

I'm not saying your analysis of use cases are false, I'm just saying that I felt the reasoning is backwards, and possibly conceptually limiting. I think the use cases should be emergent of the definition, not that the definition should be defined by (read: limited to) the typical uses.

You said ref conflated several meanings, I'm just framing it differently. I don't think it conflates them, I think they're all good uses of the tool.

On 30 September 2014 10:29, bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Manu:
>
>> Trouble for me is, I've invested so much time now.
>
>
> If your think your choice was the wrong one, don't invest even more in something you think is wasted effort.

It's not to say it's the 'wrong choice'. I'm definitely an early adopter by nature, and in the case of D, I backed the only horse than I found realistic to solve my industry's chronic abuse.

Perhaps I was being unrealistic when I thought I'd be able to get more
colleagues on board than I have?
It's just super annoying when the things that send them running are so
bloody trivial! (although, apparently important)
In the case of ref, I can't think of any programmers that I've
introduced to D that haven't complained about ref within their first
hour or 2 of interaction.
I certainly hit the wall with ref within hours of contact with D, and
6 years later, it's exactly as bad as it was within those first few
hours.

The biggest issue inhibiting people getting on board though, by far,
is the debugging experience. #1 issue, hands down.
Practical issues > language issues.


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

Manu:

> In the case of ref, I can't think of any programmers that I've
> introduced to D that haven't complained about ref within their first
> hour or 2 of interaction.

Most of the times I have no problems with D ref. Perhaps you are trying to use D too much like you use C++.


> I'd never have my PR's pulled.

"Working from the inside" also means writing patches that have a sufficiently high probability of getting pulled after some changes and improvements.


> I'm also not as interested in language development as it might appear.

Yet you discuss about language design all the time. I've discussed a lot about D, but often the topics that I have a bit more reliable opinions on are only the ones where I have direct experience (like Ranges). That's why I have suggested to write patches. With them you may be able to refine your own opinions about D.


> Yeah, it's just too weird for me to find realistic.

I don't see it so much weird. It's a lot like a C crossed with the most obvious and simplified parts of ML, plus memory areas tracking, and small bits from Erlang and C++ and little more. It contains only small amounts of OOP, exceptions and GC, and currently its generics are still first order only, so it looks simple and coesive. I think an average programmer can learn it enough to be productive for single-thread user code (not for library code) in two or three months or less. But I think you should not even try to use it as you use Ada (unlike D).

Bye,
bearophile

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;

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.

On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via Digitalmars-d wrote:
> 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.

You can probably wrap this in a nice library solution with an explicit name.

On Tuesday, 30 September 2014 at 07:18:20 UTC, deadalnix wrote:
> On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via Digitalmars-d wrote:
>> 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.
>
> You can probably wrap this in a nice library solution with an explicit name.

Hmm, I see your point... otherwise maybe user facing code survive using a string?

struct S_impl(alias T)
{
  void f(ParameterTypeTuple!T p)
  {
  }
}

template S(string decl)
{
  mixin("alias S = S_impl!((" ~ decl ~ ") {});");
}

S!"ref int x, int y" s;