May 02

On Thursday, 2 May 2024 at 07:06:34 UTC, Richard (Rikki) Andrew Cattermole wrote:

>
int adder(int a, int b) {
	alias Perform = a + b;
	return Perform;
}

This is far more expected as a feature (I have tried to do simple aliasing of variables with it in the past).

It basically offers lazy expression inlining.

ref perform() => a + b;
return perform;
May 02
Sure, they're all different.

> in C#, to pass by reference, you have to put ref also before the argument in the function call

That makes refactoring much more work. By putting ref at the function declaration, you can switch it on and off without having to change anything else.

C++ can have refs to null:

```
int *p = NULL;
int& r = *p;
```

You're not supposed to do that, but compilers don't detect it.

As for Zig, in D a ref is a single element pointer, a [] is a pointer to an array.

A special pointer to a 0 terminated array does not confer any useful semantics I can think of - one could do it in D by just making the pointer a field in a struct and overload the operators.

Essentially, we're in good shape here.
May 05
On 5/2/24 08:51, Walter Bright wrote:
>> (Of course, it would be even better if fields could also be `ref`, but then you get into initialization safety. This is a general soundness problem in the current language though.)
> 
> `ref` is not rebindable, so a `ref` field means that support is needed in the constructor or default initializer, which needs some investigation on how to do it right.

Yes, exactly. My point was we need to think about that anyway. There are other things that ought not be rebindable:

```d
@safe:
class S{
    immutable int x;
    this(int y){
        foo();
        x=y;
        foo();
    }
    static int[immutable(int)*] t;
    void foo(){
        if(&x in t) assert(t[&x]==x); // error, immutable data modified
        t[&x]=x;
    }
}

void main(){
    auto s=new S(2);
}
```

Of course, with `ref` there is an additional challenge: it cannot be default-initialized.
May 05
On 5/2/24 08:58, Walter Bright wrote:
> I forgot to mention: ref's are not rebindable:
> 
> ```
> void test(int i, int j)
> {
>      ref int r = i; // r cannot be rebound to j
> }
> ```
> This has an interesting consequence. The lifetime of the ref will always be less than the lifetime of what it was bound to.
> 

Well, not always, as not every lifetime in a program follows lexical scoping.

```d
Array!int a;
a ~= 1;
ref x = a[0];
a.length = 0;
// (`x` still alive here, but `a[0]` is not)
```

(But this is not `@safe` code.)
May 21

On Wednesday, 1 May 2024 at 21:10:54 UTC, Timon Gehr wrote:

>

On 4/12/24 22:43, Walter Bright wrote:

>

https://github.com/WalterBright/documents/blob/984374ca885e1cb10c2667cf872aebc13b4c1663/varRef.md

I think the only risk is implementation bugs in safety checks. The DIP seems a bit incomplete in this department, e.g., it does not say what happens when you take the address of a ref local. Maybe it can point to some prior art, but just stating that it cannot be returned seems neither sufficient nor necessary.

Can’t ref T reference simply be defined to have the same semantics as T* _reference and reference is a shorthand for *_reference?

>

(Of course, it would be even better if fields could also be ref, but then you get into initialization safety. This is a general soundness problem in the current language though.)

Actually, you don’t because null references are valid in D.

May 21

Apologies, all. I should have closed this thread once the thread for the second draft was started. The DIP has now been submitted and the review process is closed. Please see the final post in the second draft thread for more information:

https://forum.dlang.org/post/hpflxpmlgsnpehtqxxhe@forum.dlang.org

1 2 3 4 5
Next ›   Last »