So yeah, with the talk about 'lazy' being /adjusted/ ... how will it change? Will the syntax remain as is, or what?

Thx

kris wrote:
> So yeah, with the talk about 'lazy' being /adjusted/ ... how will it change? Will the syntax remain as is, or what?
> 
> Thx

Why does it need adjustment?

I was just getting used to it...

-David

David Medlock wrote:
> kris wrote:
> 
>> So yeah, with the talk about 'lazy' being /adjusted/ ... how will it change? Will the syntax remain as is, or what?
>>
>> Thx
> 
> 
> Why does it need adjustment?
> 
> I was just getting used to it...
> 
> -David


Seems like Andrei made some fairly scathing remarks about it, a while back? IIRC, there was some implication somewhere that it would change?

Also, how do you propogate/proxy a lazy arg? Looking at the generated code, it seems the proxy itself becomes lazy too ... that seems like a bug?

I'm asking because there's a good use-case requiring attention ...

kris wrote:
> David Medlock wrote:
>> kris wrote:
>>
>>> So yeah, with the talk about 'lazy' being /adjusted/ ... how will it change? Will the syntax remain as is, or what?
>>>
>>> Thx
>>
>>
>> Why does it need adjustment?
>>
>> I was just getting used to it...
>>
>> -David
> 
> 
> Seems like Andrei made some fairly scathing remarks about it, a while back? IIRC, there was some implication somewhere that it would change?
> 
> Also, how do you propogate/proxy a lazy arg? Looking at the generated code, it seems the proxy itself becomes lazy too ... that seems like a bug?
> 
> I'm asking because there's a good use-case requiring attention ...

Lazy is pretty messy. All qualifiers are pretty messy to define properly (within the constraints of their existing semantics and a few other essential requirements, e.g. "I don't want to see three 'const's in an expression and spend a minute figuring what each means"), and their combinations increase messiness, well, combinatorily. Just tell me quickly what "const inout lazy const char[]" means...

I don't have time to get busy with it just now, but here's a warmup question: what should, and what shouldn't pass the semantic check below?

void Fun(T, U)(T t, U u)
{
  t = 0;
  ++t;
  u[0] = 'a';
  u = "blah";
}

void main()
{
  const int x = 0;
  const char[] y = "wyda";
  Fun(x, y);
  x = 1;
  y[0] = 'a';
  y = "geeba";
}


Andrei

Andrei Alexandrescu (See Website For Email) wrote:

> Just tell me
> quickly what "const inout lazy const char[]" means...

I'm not convinced that type expression makes sense. I understand why you
can probably make some parts of a type expression const and leave others
non-const (like: a const pointer to a non-const value, or the other way
around). But not how those two consts in a row there could make a
difference. Nor how const and inout would work together. (const would
probably neutralize the out.) Nor how const/lazy or inout/lazy would
work together. But I don't know enough about 'lazy' to get deep into that.

> I don't have time to get busy with it just now, but here's a warmup question: what should, and what shouldn't pass the semantic check below?
> 
> void Fun(T, U)(T t, U u)
> {
>   t = 0;
>   ++t;
>   u[0] = 'a';
>   u = "blah";
> }

I think it would be like this:

> void main()
> {
>   const int x = 0; // No problem
>   const char[] y = "wyda"; // No problem
>   Fun(x, y); // No problem
>   x = 1; // ERROR
>   y[0] = 'a'; // NOT CERTAIN
>   y = "geeba"; // ERROR
> }

Correct me if I'm wrong.

Now, I'm not sure if it's (const char)[] or const (char[]). In other
words: A const array of chars or an array of const chars. And I'm not
sure if the second version would make sense anyway. Would a const
(dynamic array) become a static array or something?

In either case, the last assignment fails, because you're changing both the length and the content.

-- 
Michiel

Michiel wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> Just tell me
>> quickly what "const inout lazy const char[]" means...
> 
> I'm not convinced that type expression makes sense. I understand why you
> can probably make some parts of a type expression const and leave others
> non-const (like: a const pointer to a non-const value, or the other way
> around). But not how those two consts in a row there could make a
> difference. Nor how const and inout would work together. (const would
> probably neutralize the out.) Nor how const/lazy or inout/lazy would
> work together. But I don't know enough about 'lazy' to get deep into that.

That's (part of) the problem. Lazy and inout are easiest defined as type constructors (e.g. "lazy T" is a distinct type from "T"). For example, it makes sense to repeat it: "lazy lazy T" is a delegate returning a delegate that returns a T.

Making lazy and inout into qualifiers is very hard.

>> I don't have time to get busy with it just now, but here's a warmup
>> question: what should, and what shouldn't pass the semantic check below?
>>
>> void Fun(T, U)(T t, U u)
>> {
>>   t = 0;
>>   ++t;
>>   u[0] = 'a';
>>   u = "blah";
>> }
> 
> I think it would be like this:
> 
>> void main()
>> {
>>   const int x = 0; // No problem
>>   const char[] y = "wyda"; // No problem
>>   Fun(x, y); // No problem
>>   x = 1; // ERROR
>>   y[0] = 'a'; // NOT CERTAIN
>>   y = "geeba"; // ERROR
>> }
> 
> Correct me if I'm wrong.

The "NOT CERTAIN" case is an error because you can't modify the memory referred by a const object. There are errors in Fun too:

void Fun(T, U)(T t, U u)
{
  t = 0; // yah
  ++t;   // yah
  u[0] = 'a'; // nah
  u = "blah";  // yah
}

This all leads to a definition of const that is sound, but hard to explain:

1. "const T" refers only to memory indirectly addressed by T.
2. "const T name = expression" extends constness to names as well. (Another way to put it: const also acts as a storage class for name.) (Yet another way to put it: data definitions with using const are also final.)

> Now, I'm not sure if it's (const char)[] or const (char[]). In other
> words: A const array of chars or an array of const chars. And I'm not
> sure if the second version would make sense anyway. Would a const
> (dynamic array) become a static array or something?

No, it's just that the invariant is that the array itself won't change, but it can be referred to by names and slices that are rebindable.


Andrei

Speaking of const (and sorry if I'm off topic here), I'm missing something in D. Const functions like in C++. As in: functions that don't change the member vars of the class.

Is there a reason this got left out? I always thought it was useful. Could just be my C++ bias, though. ;)

-- 
Michiel

Michiel wrote:
> Speaking of const (and sorry if I'm off topic here), I'm missing
> something in D. Const functions like in C++. As in: functions that don't
> change the member vars of the class.
> 
> Is there a reason this got left out? I always thought it was useful.
> Could just be my C++ bias, though. ;)
> 

Const methods are truly useful only within a comprehensive notion of constness. The current plans are to make "const" stand for "really really const" (e.g. will not change through the lifetime of the symbol), and "in" to stand for "won't modify through this particular symbol". In essence, regular mutable data will be addressable through an "in" reference, but not through a "const" reference. Truly "const" data can be addressed via an "in" reference. Example:

void say(in char[] data)
{
  writefln(data);
}

const char[] rom = "I am super-immutable";
char[] mutable = rom.dup;

say(rom); // ok, const -> in works
say(mutable); // ok, mutable -> in works


Andrei