D Language Foundation Quarterly Meeting, October 2021

[Ali Çehreli]

Thank you, Mike. I love these digests.

On 11/5/21 4:57 AM, Mike Parker wrote:

 > One of the things
 > [Petar Kirov] would like to do is use DLang Tour to make all of the 
examples in
 > Ali's book runnable.

(That discussion must have happened when I had to leave to for another 
meeting.)

Interesting... Perhaps I can link from the chapters like "run this code 
on DLang Tour."

 > For example, a `RangeError` on an invalid array index should
 > report what the number was that caused the problem; failed asserts
 > should report the offending expression; etc.

There is great progress there already:

auto foo(int[] arr) {
   return arr[42];
}

void main() {
   foo([1, 2]);
}

core.exception.ArrayIndexError at deneme.d(1755): index [42] exceeds array 
of length 2

Awesome! :)

 > ### The fate of `-preview=in`

 > Martin, Petar, and Ali voiced strong support for the feature. Some of
 > their arguments in favor:

Another argument was "intent". As in, the programmer means "this is an 
input to this function" and the compiler does the rest. Today, both of 
the following are input parameters:

void foo(ref const(Foo) a) {}
void foo(Foo a) {}

But wait... the latter may not be an input because it may be a struct 
that has indirections that I may modify through?

How about the following "input" parameter:

void foo(const(Foo) a) {}

That 'const' has no meaning and no place there if Foo is purely a value 
type (e.g. int). Why should the knowledge of the implementation's not 
modifying that copy leak out to the interface?

I think all of that can be fixed with in(tent). ;)

void foo(in Foo a) {}

Done. In other words, dear compiler, you deal with it! :)

 > `-preview=in` will not be killed. It needs to be changed such that:

Yay!

Ali