On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote:
> Dicebot:
>
>> I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.
>
> This article talks about switching to NotNull on default in real (small) Java projects (you have to add a @NonNullByDefault at package level to change the default):
>
> http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html
>
> Bye,
> bearophile

Yes and this is exactly what we can't do in D. So what is the point of discussing library NonNull then?

Dicebot:

> Yes and this is exactly what we can't do in D.

I don't understand, if they can do that with Java, why not D?

Bye,
bearophile

On Wednesday, 9 July 2014 at 18:09:58 UTC, bearophile wrote:
> Dicebot:
>
>> Yes and this is exactly what we can't do in D.
>
> I don't understand, if they can do that with Java, why not D?
>
> Bye,
> bearophile

Java bytecode reflection makes possible to find all reference types in an attributed package and replace them to non-nullables. D compile-time reflection is currently limited to declaration (with a very 1few exceptions) - I am not aware of any ways to do it other than hot-patching generated machine code (not really an option).

One thing we can do is to validate that there are no nullable references in public signatures but this is something more suitable for static analysis rule anyway.

On 7/9/2014 3:20 AM, Dicebot wrote:
> Last time we talked about it during dconf you have mentioned doing necessary
> escape analysis for borrowing semantics is too complicated to consider :) Ad if
> you don't mean transitive, you shouldn't refer to Rust borrowing terminology as
> any ownership type is normally transitive there.

Yes, I mean transitive, and understand what that implies.


>> 5. Precise and Concurrent GC
>>
>> There's been a lot of work on this, but I don't know where we stand on it.
>
> I have started work on porting the CDGC to D2, have compilable version (that was
> easy thanks to earlier Sean work) but updating implementation to match new
> druntime and pass tests will take quite some time.

Is CDGC's Luca's earlier work on concurrent GC?


>> 7. "D-Routines" - goroutines for D
>>
>> Goroutines are the killer feature of Go for a number of sensible people. We
>> pretty much have this already with fibers, but what is lacking is a scheduler,
>> which will take some effort, and a "Channel" type, which should be easy.
>
> I'd state it differently: "Marketing fuss about goroutines is the killer feature
> of Go" :) It does not have any fundamental advantage over existing actor model
> and I doubt it will matter _that_ much.

Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.



>> 8. NotNull!T type
>>
>> For those that want a non-nullable reference type. This should be doable as a
>> library type.
>
> I don't know where it comes from but non-nullable reference type has ZERO value
> if it is not the default one.

Making it the default is impossible for D. However,

  class _C { ... }
  alias NotNull!_C C;

is entirely practical. It's not unlike the common C practice:

  typedef struct S { ... } S;

to bring S out of the tag name space.

On 7/9/2014 7:37 AM, Timon Gehr wrote:
> On 07/08/2014 11:22 PM, Walter Bright wrote:
>> 3. 'ref' means 'borrowed', to use Rust's terminology
>> We're almost there with this. This means better escape analysis, too.
> What makes you think that 'ref' is a good match for this functionality, and how
> are we almost there with this?

'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored, and one cannot take the address of a ref'd variable in @safe code.



>> 8. NotNull!T type
>>
>> For those that want a non-nullable reference type. This should be doable
>> as a library type.
> No.

Rationale?

On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote:
> I would, except that I'm unsure of exactly what is needed in said
> design.

I'm unsure as well. That's why design work is needed!

> Are we just trying to nail down the exact semantics of 'scope'?
> Or are we looking at implementational issues (possible compiler
> performance hits)? Or both? Or something else altogether? Do we need to
> account for (what little exists of) the current implementation? Speaking
> of which, what *is* the current extent of the implementation of 'scope'?
> I assume it isn't just a no-op, since I see it applied to delegate
> parameters every now and then?

Yes, yes, yes, ... these are questions that all need investigation and answering.

Walter Bright:

> Making it the default is impossible for D.

Is it impossible any strategy analogous to the Java one, as visible in the link I've shown earlier in this thread?
http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html

Bye,
bearophile

On 7/9/2014 8:38 AM, Nick Treleaven wrote:
> On 08/07/2014 23:40, Remo wrote:
>>> What about the already present std.typecons.Unique?
>>
>> Unfortunately there are a lot of /+Doesn't work yet+/ comments in
>> std.typecons.Unique code.
>
> I think it was written a long time ago. I think much of those parts will work
> now. I'm slowly going through them and will make more PRs, here's the first one,
> to disable postblit:
>
> https://github.com/D-Programming-Language/phobos/pull/2308

More things that need to happen with Unique:

  Unique!T u = ...;
  immutable p = u;    // unique references can be implicitly cast to immutable

  Unique!(int*) u = new int;   // must work

  int* p = new int;
  Unique!(int*) u = p;         // must fail

On 7/9/2014 12:54 PM, bearophile wrote:
> Walter Bright:
>
>> Making it the default is impossible for D.
>
> Is it impossible any strategy analogous to the Java one, as visible in the link
> I've shown earlier in this thread?
> http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html


That's essentially just adding an attribute, like:

   @nogc:

to the beginning of a module. It's not making it the default.

On Wed, Jul 09, 2014 at 12:51:40PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote:
> >I would, except that I'm unsure of exactly what is needed in said design.
> 
> I'm unsure as well. That's why design work is needed!
> 
> >Are we just trying to nail down the exact semantics of 'scope'?
> >Or are we looking at implementational issues (possible compiler
> >performance hits)? Or both? Or something else altogether? Do we need to
> >account for (what little exists of) the current implementation? Speaking
> >of which, what *is* the current extent of the implementation of 'scope'?
> >I assume it isn't just a no-op, since I see it applied to delegate
> >parameters every now and then?
> 
> Yes, yes, yes, ... these are questions that all need investigation and answering.

Surely the last question doesn't need *investigation* per se?? Or do we really have no idea whatsoever as to what 'scope' currently does in dmdfe at all?


T

-- 
Meat: euphemism for dead animal. -- Flora