On 7/9/14, 12:55 PM, Walter Bright wrote:
> 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

Hmmm... how about using u after that?


Andrei

Walter Bright:

> That's essentially just adding an attribute, like:
>
>    @nogc:
>
> to the beginning of a module. It's not making it the default.

Is it possible & useful & good to put something like a "@not_null_references:" (or a similar pragma) at the top of a module? How are differently defaulting modules going to interact with each other?

(I think F# code originally had verbose syntax, plus a "#light" module annotation to allow the use of a lighter Haskell-like syntax with the same semantics. The light syntax was so popular that later the default mode was switched with the light mode.)

Bye,
bearophile

Walter Bright:

> That's essentially just adding an attribute, like:
>
>    @nogc:
>
> to the beginning of a module.

I think in the Java case it's more a package-level annotation instead of module-level one.

Bye,
bearophile

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

I've used the Eclipse annotations with some success when writing Java code, which I do primarily for Android these days. If we were to ever transition to non nullable references by default, annotations would be a good way to make that transition. @notnull can be used to disallow setting null on references, so it can check for things like initialising a non-nullable reference in a constructor. @nullable would available for doing what is already true for references. Then Option(T) could be available as a library solution, which can hold a @nullable inside it and perform the necessary runtime checking and casting to @notnull T. Then you put things through a long deprecation cycle and the billion dollar mistake is finally corrected.

There's a pipedream, anyway.

On 7/9/2014 1:09 PM, H. S. Teoh via Digitalmars-d wrote:
> 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?


What I'm saying is there is not a design. A design needs to be created. Figuring out where we are, where we need to get to, and how to get there is what is needed. Please help.

On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
> Hmmm... how about using u after that?

Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.

On Wednesday, 9 July 2014 at 20:49:00 UTC, w0rp wrote:
> <much yammering on>

I should note that there is some merit to having Option(T) even without T being non-nullable by default, as it at least gives you the ability to look at an API and find out where you'll need to deal with the None case.

T foo();
U bar();
V baz();

Doesn't say as much as.

T foo();
Option!U bar();
V baz();

Even doing these things without strong compile time checks is a big step up.

On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
> On 7/9/2014 3:20 AM, Dicebot wrote:
>>
>> 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.

I think it still mostly comes down to marketing :-)  That said,
we're pretty close in D once my Scheduler pull request is
accepted.  Between that and the Generator type in the same pull
request, we're not missing much but the weird switch syntax they
have.  There's still some work to do, but I think a lot of it
really comes down to showing people what's already possible in D
rather than writing more code.

Am Wed, 9 Jul 2014 13:09:30 -0700
schrieb "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com>:

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

So this was not a rhetoric question?
For delegates scope can prevent closure heap allocation. For all other
types it does nothing. Example:

import std.stdio;

void testA(void delegate() cb)
{
    cb();
}
void testB(scope void delegate() cb)
{
    cb();
}

void main()
{
    int a;
    void callback() {a = 42;}
//Callback accesses a, testA might store a reference to callback
//->a might be accessible after this main function returns
//->can't keep it on the stack. Allocate a on the heap
    testA(&callback);

//Callback accesses a, but testB does not store a reference
//as it tells us by using scope
//So as soon as testB returns, there's no reference to a floating
//around and we can allocate a on the stack.
//(Of course as long as we call testA in this function, a is always on
// the heap. but if we only call testB it can be on the stack)
    testB(&callback);
}

On 7/9/14, 1:51 PM, Walter Bright wrote:
> On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
>> Hmmm... how about using u after that?
>
> Using u after that would either cause an exception to be thrown, or
> they'd get T.init as a value. I tend to favor the latter, but of course
> those decisions would have to be made as part of the design of Unique.

That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei