torhu wrote

> It's not a contradiction.  Only references that are actually inside your application are relevant for this rule.

Very true. If one restricts the application to local copies, then the rule cannot be violated---but then the rule is ineffective also.

This seems to shout for a formalization of the scope rule.

-manfred

Walter Bright wrote:
> This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.
> 
> 'in' will mean 'scope const final', which means:
> 
> final - the parameter will not be reassigned within the function
> const - the function will not attempt to change the contents of what is referred to
> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function
> 
> For example:
> 
> int[] g;
> 
> void foo(in int[] a)
> {
>      a = [1,2];	// error, a is final
>      a[1] = 2;   // error, a is const
>      g = a;	// error, a is scope
> }
> 
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

If you've got a C library with a header file containing this:

// C header file
void f(const char* p);

Is there any reason why you should think twice before turning it into this D code, and link it with the C library, not knowing anything about the implementation of f?

// D import module
extern (C) void f(in char* p);


Without reading the docs for f, would it be better to just go with 'const'?  In that case it won't be backwards compatible with D 1.0 anymore.  If I get the meaning of 'scope' correctly, that's the one that can cause problems here.

torhu wrote:
> If you've got a C library with a header file containing this:
> 
> // C header file
> void f(const char* p);
> 
> Is there any reason why you should think twice before turning it into this D code, and link it with the C library, not knowing anything about the implementation of f?
> 
> // D import module
> extern (C) void f(in char* p);
> 
> 
> Without reading the docs for f, would it be better to just go with 'const'?  In that case it won't be backwards compatible with D 1.0 anymore.  If I get the meaning of 'scope' correctly, that's the one that can cause problems here.

I'd go with:

	f(const char* p);

because that expresses the C semantics. Using 'in' will cause problems if f() stores p somewhere.

Perhaps we need a D2.0.learn newsgroup?  Would we also need to make 2.0 of the others?

-Joel

I've only now been able to read this thread, so, just some simple questions:

Walter Bright wrote:
> This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.
> 
> 'in' will mean 'scope const final', which means:
> 
> final - the parameter will not be reassigned within the function
> const - the function will not attempt to change the contents of what is referred to
> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function
> 

Does this mean you have finished a working design for const/final/invariant/etc. ? If so, then what is the type of fooptr here? :
  final foo;
  auto fooptr = &foo;

> For example:
> 
> int[] g;
> 
> void foo(in int[] a)
> {
>     a = [1,2];    // error, a is final
>     a[1] = 2;   // error, a is const
>     g = a;    // error, a is scope
> }
> 
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

Whoa there, that idea of 'scope' being the default togheter with 'const' and 'final', where did that came from? I understand why (and agree) that 'final' and 'const' should be the default type modifiers for function parameters, but why 'scope' as well?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

I'm appalled, both that this is pretty much assured to be in D , and that the community seems to be behind it.  I thought that the reason Walter didn't want const was because of its added complexity , so instead he introduces _3_ new keywords ?  Does no one else feel like this is using a machine gun to kill a fly ?

I understand the need for immutable data when writing libraries, but 'scope const final MyClass myInstance' ?!?  Theres got to be a better way.

I know this sounds over-dramatic, but if this is the direction D is headed, then count me out.  I loved D because if its elegant and powerful simplicity, I think D has strayed way to far from its original goal.

If anyone feels like _this_ implementation for const ( not the usefulness of const mind you ) is not for D, then please speak up or we all might end up losing our favorite language.

Charlie

Walter Bright wrote:
> This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.
> 
> 'in' will mean 'scope const final', which means:
> 
> final - the parameter will not be reassigned within the function
> const - the function will not attempt to change the contents of what is referred to
> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function
> 
> For example:
> 
> int[] g;
> 
> void foo(in int[] a)
> {
>     a = [1,2];    // error, a is final
>     a[1] = 2;   // error, a is const
>     g = a;    // error, a is scope
> }
> 
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

"Charlie" <charlie.fats@gmail.com> wrote in message news:46649DD9.1010801@gmail.com...
> I'm appalled, both that this is pretty much assured to be in D , and that the community seems to be behind it.  I thought that the reason Walter didn't want const was because of its added complexity , so instead he introduces _3_ new keywords ?  Does no one else feel like this is using a machine gun to kill a fly ?
>
> I understand the need for immutable data when writing libraries, but 'scope const final MyClass myInstance' ?!?  Theres got to be a better way.
>
> I know this sounds over-dramatic, but if this is the direction D is headed, then count me out.  I loved D because if its elegant and powerful simplicity, I think D has strayed way to far from its original goal.
>
> If anyone feels like _this_ implementation for const ( not the usefulness of const mind you ) is not for D, then please speak up or we all might end up losing our favorite language.
>

I was beginning to think I was the only one.  It doesn't seem any easier than the C++ style const-ness at all.  If anything it's more complex. Instead of "here a const, there a const, everywhere a const * const" it seems like it'll be "here a const, there a final, everywhere an invariant scope int[new]" :P

Jarrett Billingsley wrote:
> "Charlie" <charlie.fats@gmail.com> wrote in message news:46649DD9.1010801@gmail.com...
>> I'm appalled, both that this is pretty much assured to be in D , and that the community seems to be behind it.  I thought that the reason Walter didn't want const was because of its added complexity , so instead he introduces _3_ new keywords ?  Does no one else feel like this is using a machine gun to kill a fly ?
>>
>> I understand the need for immutable data when writing libraries, but 'scope const final MyClass myInstance' ?!?  Theres got to be a better way.
>>
>> I know this sounds over-dramatic, but if this is the direction D is headed, then count me out.  I loved D because if its elegant and powerful simplicity, I think D has strayed way to far from its original goal.
>>
>> If anyone feels like _this_ implementation for const ( not the usefulness of const mind you ) is not for D, then please speak up or we all might end up losing our favorite language.
>>
> 
> I was beginning to think I was the only one.  It doesn't seem any easier than the C++ style const-ness at all.  If anything it's more complex. Instead of "here a const, there a const, everywhere a const * const" it seems like it'll be "here a const, there a final, everywhere an invariant scope int[new]" :P 

I think we should wait and see how it comes out.  Of course expressing your doubts and misgivings is a good thing too, but, yeh, let's try not to be over-dramatic.  Naturally the discussion here tends to revolve around the cases that aren't obvious or straightforward, because the obvious, easy cases need no discussion.  So it's natural that it ends up sounding like "everywhere an invariant scope int[new]", but I suspect in typical code such things will be uncommon.

I'm not sure about this int[*] thing though. That will probably require a lot of changes whether int[*] ends up meaning resizeable or not.  But come on, you have to admit that slices are a little dicey, and giving the compiler a way to detect bogus usage of a slice will be good. They're supposed to be a safer alternative to naked pointers, but instead they introduce their own equivalently dangerous set of gotchas due to the ambiguity of ownership.

Other than that, I think pretty much all of the changes Walter has mentioned will be ignorable.

--bb

Bill Baxter wrote:
> Jarrett Billingsley wrote:
>> "Charlie" <charlie.fats@gmail.com> wrote in message news:46649DD9.1010801@gmail.com...
>>> I'm appalled, both that this is pretty much assured to be in D , and that the community seems to be behind it.  I thought that the reason Walter didn't want const was because of its added complexity , so instead he introduces _3_ new keywords ?  Does no one else feel like this is using a machine gun to kill a fly ?
>>>
>>> I understand the need for immutable data when writing libraries, but 'scope const final MyClass myInstance' ?!?  Theres got to be a better way.
>>>
>>> I know this sounds over-dramatic, but if this is the direction D is headed, then count me out.  I loved D because if its elegant and powerful simplicity, I think D has strayed way to far from its original goal.
>>>
>>> If anyone feels like _this_ implementation for const ( not the usefulness of const mind you ) is not for D, then please speak up or we all might end up losing our favorite language.
>>>
>>
>> I was beginning to think I was the only one.  It doesn't seem any easier than the C++ style const-ness at all.  If anything it's more complex. Instead of "here a const, there a const, everywhere a const * const" it seems like it'll be "here a const, there a final, everywhere an invariant scope int[new]" :P 
> 
> I think we should wait and see how it comes out.  Of course expressing your doubts and misgivings is a good thing too, but, yeh, let's try not to be over-dramatic.  Naturally the discussion here tends to revolve around the cases that aren't obvious or straightforward, because the obvious, easy cases need no discussion.  So it's natural that it ends up sounding like "everywhere an invariant scope int[new]", but I suspect in typical code such things will be uncommon.
> 

Recalling the resistance that Walter originally had to adding const (the 'loose' semantics of C++ const and the concern about "littering" D code w/ const), I too think it will be wise to see what Walter has come up with. I'm pretty confident it will be both better and less onerous than C++ const for a majority of situations given the quality of design (of D) in other areas.

> I'm not sure about this int[*] thing though. That will probably require a lot of changes whether int[*] ends up meaning resizeable or not.  But come on, you have to admit that slices are a little dicey, and giving the compiler a way to detect bogus usage of a slice will be good. They're supposed to be a safer alternative to naked pointers, but instead they introduce their own equivalently dangerous set of gotchas due to the ambiguity of ownership.
> 
> Other than that, I think pretty much all of the changes Walter has mentioned will be ignorable.
> 
> --bb

Charlie wrote:
> I'm appalled, both that this is pretty much assured to be in D , and that the community seems to be behind it.  I thought that the reason Walter didn't want const was because of its added complexity , so instead he introduces _3_ new keywords ?  Does no one else feel like this is using a machine gun to kill a fly ?
> 
> I understand the need for immutable data when writing libraries, but 'scope const final MyClass myInstance' ?!?  Theres got to be a better way.
> 
> I know this sounds over-dramatic, but if this is the direction D is headed, then count me out.  I loved D because if its elegant and powerful simplicity, I think D has strayed way to far from its original goal.
> 
> If anyone feels like _this_ implementation for const ( not the usefulness of const mind you ) is not for D, then please speak up or we all might end up losing our favorite language.

Actually, I quite empathize with your viewpoint. I worry that the final, const, invariant thing is too complicated. But there are some mitigating factors:

1) Just as in C++, you can pretty much ignore final, const, and invariant if they don't appeal to you. I don't bother using const in my C++ code.

2) The transitive nature of const means that there are a lot fewer const's you have to write.

3) Using D's type inference capability, a lot fewer types (and their attendant const's) need to be written.

4) It provides information that is actually useful to the compiler.

5) Scope has the promise of enabling reference counting to be far more efficient than is possible in C++.

6) Working together, these features move us towards supporting the functional programming paradigm better. FP is very important for the future, as it is very adaptable to parallel programming.

7) They make interfaces much more self-documenting.

8) They can make automated code analysis tools more effective. Automated code analysis is big business and is getting to be far more important as security consultants are brought in to analyze code for correctness, security, etc. Wall Street in particular is very interested in this stuff.

9) So far, in my work to make Phobos const-correct, it hasn't been the annoyance I thought it would be.