September 12, 2007
renoX a écrit :
> Derek Parnell a écrit :
>> Thank you. I do remember now ... silly how I couldn't get that from the
>> keywords.
>>
>> 'const' is sort of a locally write protected.
>> 'invariant' is globally write protected.
> 
> So am I, each time I see 'invariant' I try to think 'value', which is much more easy to associate with the correct properties:
> values are immutable and you can't take the address of a value either, exactly like 'invariant'.

Oops, I didn't see the change that now you can take the address of an invariant.

So now invariant != value, argh.

renoX
> 
> For const, I've not found an easy to memorize keyword, but as D's const are like C++ const (AFAIK), it's not an issue for me.
> 
> 
> Of course with a Limbo syntax for variable declaration instead of the weird C-like, the parenthesis would be less(not?) useful..
> 
> renoX
September 12, 2007
On Tue, 11 Sep 2007 10:10:33 +0100, Janice Caron wrote:

> On 9/11/07, Derek Parnell <derek@nomail.afraid.org> wrote:
>>
>> In other words, if I have a struct with three members, each of a different type, I need to code ...
>>
>> struct S3(T, U, V)
>> {
>>    T member1;
>>    U member2;
>>    V member3;
>> }
>>
>> S3!(const(int), const(float), const(bool));
>>
>> and so on for 4, 5, 6, .... 23 member structs.
>>
>> I'm sure I'm misunderstanding you, because this is really silly.
>>
> 
> I don't think you're misunderstanding. I think that's what Walter is saying.

But why templates?!?!?

How is that different from ...

 struct S3
 {
    const(int) member1;
    const(float) member2;
    const(bool) member3;
 }

No template involved.

I'm reading Walter as saying that if any struct definition involves any of its members being const/invariant, then one must define that struct in terms of templates. Is this what Walter is really saying?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
12/09/2007 6:31:57 PM
September 12, 2007
Derek Parnell wrote:
> On Tue, 11 Sep 2007 10:10:33 +0100, Janice Caron wrote:
> 
>> On 9/11/07, Derek Parnell <derek@nomail.afraid.org> wrote:
>>> In other words, if I have a struct with three members, each of a different
>>> type, I need to code ...
>>>
>>> struct S3(T, U, V)
>>> {
>>>    T member1;
>>>    U member2;
>>>    V member3;
>>> }
>>>
>>> S3!(const(int), const(float), const(bool));
>>>
>>> and so on for 4, 5, 6, .... 23 member structs.
>>>
>>> I'm sure I'm misunderstanding you, because this is really silly.
>>>
>> I don't think you're misunderstanding. I think that's what Walter is saying.
> 
> But why templates?!?!?
> 
> How is that different from ...
> 
>  struct S3
>  {
>     const(int) member1;
>     const(float) member2;
>     const(bool) member3;
>  }
> 
> No template involved.
> 
> I'm reading Walter as saying that if any struct definition involves any of
> its members being const/invariant, then one must define that struct in
> terms of templates. Is this what Walter is really saying?

No, I don't think so.

I believe he is saying that if you have a struct, eg.

struct S1
{
  int a;
  float b;
}

and you want to use it, as is, in one place in your code but also use a const version of this same struct somewhere else then you need to use a template to create a modified struct definition to use.

If you simply want to convert a struct from non-const aware to const-aware you can just add const to the definition and recompile.

If you simply want to have a const copy of the struct somewhere you can just use const(S1), eg.

class Bob
{
  const(S1) data;
}

Regan
September 12, 2007
Regan Heath wrote:
> Derek Parnell wrote:
>> On Tue, 11 Sep 2007 10:10:33 +0100, Janice Caron wrote:
>>
>>> On 9/11/07, Derek Parnell <derek@nomail.afraid.org> wrote:
>>>> In other words, if I have a struct with three members, each of a different
>>>> type, I need to code ...
>>>>
>>>> struct S3(T, U, V)
>>>> {
>>>>    T member1;
>>>>    U member2;
>>>>    V member3;
>>>> }
>>>>
>>>> S3!(const(int), const(float), const(bool));
>>>>
>>>> and so on for 4, 5, 6, .... 23 member structs.
>>>>
>>>> I'm sure I'm misunderstanding you, because this is really silly.
>>>>
>>> I don't think you're misunderstanding. I think that's what Walter is saying.
>>
>> But why templates?!?!?
>>
>> How is that different from ...
>>
>>  struct S3
>>  {
>>     const(int) member1;
>>     const(float) member2;
>>     const(bool) member3;
>>  }
>>
>> No template involved.
>>
>> I'm reading Walter as saying that if any struct definition involves any of
>> its members being const/invariant, then one must define that struct in
>> terms of templates. Is this what Walter is really saying?
> 
> No, I don't think so.
> 
> I believe he is saying that if you have a struct, eg.
> 
> struct S1
> {
>   int a;
>   float b;
> }
> 
> and you want to use it, as is, in one place in your code but also use a const version of this same struct somewhere else then you need to use a template to create a modified struct definition to use.
> 
> If you simply want to convert a struct from non-const aware to const-aware you can just add const to the definition and recompile.
> 
> If you simply want to have a const copy of the struct somewhere you can just use const(S1), eg.
> 
> class Bob
> {
>   const(S1) data;
> }

To clarify (I hope).

A template is only required if you want to _tail_ const certain members (or even all) of an existing struct in some instances but not all instances.

Complete const can be achived with const(S1) and tail const on all instances can be achieved by editing the struct difinition and recompiling.

Regan
September 12, 2007
Yes.  Const does suck.

Walter Bright wrote:

> Const, final, invariant, head const, tail const, it's grown into a monster. It tries to cover all the bases, but in doing so is simply not understandable.
> 
> Andrei and Bartosz have spent some time together going back to square one with what are we trying to achieve with const, and came up with another proposal.
> 
> What we are trying to achieve:
> 
> a) utility for functional programming
> b) better modularity by self-documenting interfaces better
> c) be able to treat reference types as if they were value types (i.e. strings should behave to the user like value types, even though they are references)
> 
> The insights they came up with were:
> 
> 1) final (i.e. 'head const') is not necessary for a, b or c. final is a local thing, and not strictly necessary.
> 
> 2) tail const can be handled in other ways, read on
> 
> So, what we are left with is:
> 
> o  no more final
> 
> o  const and invariant now mean "fully const" and "fully invariant", where fully means "head and tail combined":
> 
> const int x = 0;   // x is constant
> const int* p = &x;  // neither p nor *p can be changed
> const(int*) p = &x;  // neither p nor *p can be changed
> const(int)* p = &x;  // p can change, *p cannot be changed
> 
> o  const and invariant are transitive. There is no way to specify a (pointer to)(const pointer to)(mutable int).
> 
> o  tail invariant for an array or pointer type can be done using the existing syntax:
> 
>  invariant(char)[] s;   // string, i.e. an array of invariant chars
>  const(T)* p;  // pointer to tail const T
> 
> o  tail const of a struct would have to be done by making the struct a template:
> 
>   struct S(T) { T member; }
>   S!(int)   // tail mutable
>   S!(const(int)) // tail const
> 
> o  one can construct a template to generically produce tail const or tail invariant versions of a type.
> 
> o  it will be illegal to attempt to change the key value of a foreach loop, but the compiler will not be able to diagnose all attempts to do so
> 
> o  static const/invariant means the initializer is evaluated at compile time. non-static const/invariant means it is evaluated at run time.
> 
> o  no initializer means it is assigned in the corresponding constructor.
> 
> o  const/invariant declarations will always allocate memory (so their addresses can be taken)
> 
> o  So, we still need a method to declare a constant that will not consume memory. We'll co-opt the future macro syntax for that:
> 
>     macro x = 3;
>     macro s = "hello";
September 13, 2007
Ok, seems my Oskar "agreing spree" has ended. :P

Oskar Linde wrote:
>
> TransitiveReadonly!() is possible to implement.
> 

Are you sure? How would that work in general terms, for say, a class?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
2 3 4 5 6 7 8 9 10 11 12
Next ›   Last »