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