kris wrote:
> Walter Bright wrote:
> 
>> Bug fixes, some enhancements.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.011.zip
> 
> 
> 
> ----
> struct HttpStatus
> {
>         int     code;
>         char[]  name;
> }
> 
> struct HttpResponses
> {
>         final HttpStatus Continue = {100, "Continue"};
> }
> 
> void foo (inout HttpStatus status)
> {
> }
> 
> void main ()
> {
>         foo (HttpResponses.Continue);
> }
> ---
> 
> "Error: cannot modify final variable 'Continue'"
> 
> The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference?
> 
> (if you change 'final' to 'const' within the HttpResponses struct, the same error is generated, and saying "final" rather than "const")
> 


In a similar fashion, this kinda' thing used to work just fine:

---
struct Foo
{
	final char[] x;
}

static Foo foo = {"something"};
---

"Error: too many initializers"

How is one now supposed to declare struct contents that are immutable after being set to an initial value?

Serg Kovrov wrote:
> freeagle wrote:
>> what was wrong with "inout" ?
> 
> Nothing. I hope 'inout' will stay "read-write reference" (&), and 'ref' will become "read-only reference" (const &). Although 'in' seems better name for it... But well, we'll see.
> 
i agree. in, out and inout seem more "natural" to me than ref or anything else. Even newcomer will guess what they mean, ref looks more cryptic

Hasan Aljudy wrote:
> Walter Bright wrote:
>> For the future (unimplemented) AST macro feature.
> 
> Aha! Sounds interesting ..
> I haven't been following the discussions lately, was this discussed somewhere? I'd like to see .. like; what kind of ideas are laid out on the table? Do you have something specific in mind?

I think there was a thread entitled "AST macros" a month ago.

kris wrote:
> Walter Bright wrote:
>> Bug fixes, some enhancements.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.011.zip
> 
> 
> ----
> struct HttpStatus
> {
>         int     code;
>         char[]  name;
> }
> 
> struct HttpResponses
> {
>         final HttpStatus Continue = {100, "Continue"};
> }
> 
> void foo (inout HttpStatus status)
> {
> }
> 
> void main ()
> {
>         foo (HttpResponses.Continue);
> }
> ---
> 
> "Error: cannot modify final variable 'Continue'"
> 
> The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference?

In the future, inout would be replaced with "const ref".


> (if you change 'final' to 'const' within the HttpResponses struct, the same error is generated, and saying "final" rather than "const")
> 

kris wrote:
> In a similar fashion, this kinda' thing used to work just fine:
> 
> ---
> struct Foo
> {
>     final char[] x;
> }
> 
> static Foo foo = {"something"};
> ---
> 
> "Error: too many initializers"
> 
> How is one now supposed to declare struct contents that are immutable after being set to an initial value?

That looks like a compiler bug.

Walter Bright wrote:
> kris wrote:
>> Walter Bright wrote:
>>> Bug fixes, some enhancements.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> http://ftp.digitalmars.com/dmd.1.011.zip
>>
>>
>> ----
>> struct HttpStatus
>> {
>>         int     code;
>>         char[]  name;
>> }
>>
>> struct HttpResponses
>> {
>>         final HttpStatus Continue = {100, "Continue"};
>> }
>>
>> void foo (inout HttpStatus status)
>> {
>> }
>>
>> void main ()
>> {
>>         foo (HttpResponses.Continue);
>> }
>> ---
>>
>> "Error: cannot modify final variable 'Continue'"
>>
>> The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference?
> 
> In the future, inout would be replaced with "const ref".

Hm... so what should be done to get this working until the new 'const' semantics are in place?


Sean

freeagle wrote:
> Walter Bright wrote:
>> Bug fixes, some enhancements.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.011.zip
> 
> what was wrong with "inout" ?

Got me.  in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent.  I can't say I understand the reason for a new keyword here.


Sean

Sean Kelly wrote:

> freeagle wrote:
>> Walter Bright wrote:
>>> Bug fixes, some enhancements.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> http://ftp.digitalmars.com/dmd.1.011.zip
>> 
>> what was wrong with "inout" ?
> 
> Got me.  in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent.  I can't say I understand the reason for a new keyword here.
> 
> 
> Sean

What's more it is common notation in UML tools - there is no 'ref' but there is in/out/inout.

So why to change?

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Hasan Aljudy wrote:
> > Walter Bright wrote:
> >> For the future (unimplemented) AST macro feature.
> >
> > Aha! Sounds interesting ..
> > I haven't been following the discussions lately, was this discussed
> > somewhere? I'd like to see .. like; what kind of ideas are laid out on
> > the table? Do you have something specific in mind?
> I think there was a thread entitled "AST macros" a month ago.

Here are links to some of the posts in the "AST macros" thread:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50484 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50595 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50619 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50684

Or if people prefer to view the archives: http://www.digitalmars.com/d/archives/digitalmars/D/AST_macros_50484.html

(Random note: By the way, the web interface's threading doesn't seem to work as well here as it does with some other threads. I wonder why that is. Anyway, it's still better than nothing.)

jcc7

Walter Bright wrote:
> In the future, inout would be replaced with "const ref".

To me it's 'in' seems more like constant reference, but 'inout' like just reference.

Anyway, why to replace in/out/inout? Just change 'in' to be "const ref".

-- 
serg.