On Thursday, 10 July 2014 at 20:31:53 UTC, Walter Bright wrote:
>
> I reiterate my complaint that people use "virtual functions" for their github handles. There's no reason to.

Collisions?  "Walter Bright" might be reasonably uncommon, but I
have to compete with one of the most famous cyclists of all time!
:-)  To compensate, I use the same "virtual function" literally
everywhere.  Same icon photo too.  Take that, cyberstalkers!

On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
>     struct S {
>         int* p;
>         void releaseBuffer() scope {
>             // `scope` in the signature applies to `this`
>             free(this.p);
>             this.p = null;
>         }
>     }
>     int bar(scope ref S a, scope int* b) {
>         a.releaseBuffer();
>         return *b; // use after free
>     }
>     S s;
>     bar(s, s.p);
>
> The root cause of the problem here is the call to `free()`. I _believe_ the solution is that `free()` (and equivalent functions of allocators as well as `delete`) must not accept scope parameters.

Thinking more about it:

    struct S {
         int* p;
         void releaseBuffer() scope {
             free(this.p);
             this.p = null;
         }
     }
     int bar(void delegate() a, scope int* b) {
         a();
         return *b; // use after free
     }
     S s;
     bar({ s.releaseBuffer(); }, s.p);

So, for what I suggested (`free()` mustn't accept scope) to work, an additional rule is required: While a borrowed reference exist, the original must also be treated as scope.

Now, this is much more complicated to implement :-( Maybe there's a better way?

On Thursday, 10 July 2014 at 21:40:15 UTC, Sean Kelly wrote:
> :-)  To compensate, I use the same "virtual function" literally
> everywhere.  Same icon photo too.

That's Go…

On 7/10/2014 2:40 PM, Sean Kelly wrote:
> Collisions?  "Walter Bright" might be reasonably uncommon, but I
> have to compete with one of the most famous cyclists of all time!
> :-)  To compensate, I use the same "virtual function" literally
> everywhere.  Same icon photo too.  Take that, cyberstalkers!

Heck, use "TheRealSeanKelly", or "ComplexMathSeanKelly" or "SKelly" or "NotSeanPenn" :-)

On 7/10/2014 1:52 PM, bearophile wrote:
> Walter Bright:
>
>> I can't imagine users going to the bother of typing all that, let alone what
>> happens when they do it wrong. Most users don't really have a good handle on
>> what the lifetimes of their data are, so how are they going to annotate it
>> correctly?
>
> I suggest you to go in the Rust mailing list and ask this question again.

Rust has very little experience in real projects. I know that people see all the hype about Rust and believe it has proved itself, but it hasn't.

I've read other papers about annotations in Java and how people just refused to annotate their references.

On 7/10/2014 1:57 PM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> That leaves relatively few cases

Right, and do those cases actually matter?

I'm a big believe in attribute inference, because explicit attributes are generally a failure with users.

On 07/10/2014 10:41 PM, Walter Bright wrote:
> On 7/10/2014 11:53 AM, Timon Gehr wrote:
>> Are you talking about the concept, the examples, or just the last
>> example? What
>> makes it seem complicated?
>
> I can't imagine users going to the bother of typing all that,

As explicitly stated this was just for demonstration. Feel free to propose concise syntax.

> let alone
> what happens when they do it wrong. Most users don't really have a good
> handle on what the lifetimes of their data are, so how are they going to
> annotate it correctly?

If they do it wrong it is not going to compile.

On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d wrote:

Can you copy and paste the text from your original post? It's difficult to read on the web interface.

On Thursday, 10 July 2014 at 18:16:57 UTC, H. S. Teoh via Digitalmars-d wrote:
> There is an interesting subtlety here, in that local variables
> themselves are not necessarily scoped, for example:
>
> 	class C {}
> 	C createObj() {
> 		auto obj = new C;	// obj is a local variable
> 		return obj;		// but its lifetime can be extended outside the function
> 	}

They are scoped, but to the lifetime of the GC, which is the length of the program. Anything that the GC owns can safely be marked scope(static) or however you would write it.

On 7/10/14, 2:25 PM, Walter Bright wrote:
> On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
>> https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither
>
> I want to defer this to Andrei.

Merged. -- Andrei