Thread overview
Proper way to protect (lock) a struct field after initialization ??
Aug 08, 2021
james.p.leblanc
Aug 08, 2021
jfondren
Aug 08, 2021
james.p.leblanc
Aug 08, 2021
Ali Çehreli
Aug 08, 2021
james.p.leblanc
August 08, 2021

Hello All.

Is there a standard way to protect a field of a struct after
the struct has been initialized?

Is this possible with a struct?

If not, I suppose a class (object) would be needed? If so,
are there any simple pointers to an example of this?

Thanks in advance,

James

August 08, 2021

On Sunday, 8 August 2021 at 10:11:37 UTC, james.p.leblanc wrote:

>

Hello All.

Is there a standard way to protect a field of a struct after
the struct has been initialized?

Is this possible with a struct?

If not, I suppose a class (object) would be needed? If so,
are there any simple pointers to an example of this?

Thanks in advance,

James

private works for structs the same as it does for classes.
https://dlang.org/spec/attribute.html#visibility_attributes

Perhaps you tried it, realized you could still access it within the same module, and concluded that it didn't work? Consider note #2 at that link: "Symbols with private visibility can only be accessed from within the same module." Import the struct into another module and test the visibility there and you'll get the behavior you're looking for.

August 08, 2021

On Sunday, 8 August 2021 at 10:19:46 UTC, jfondren wrote:

>

On Sunday, 8 August 2021 at 10:11:37 UTC, james.p.leblanc wrote:

>

Hello All.

Is there a standard way to protect a field of a struct after
the struct has been initialized?

Is this possible with a struct?

If not, I suppose a class (object) would be needed? If so,
are there any simple pointers to an example of this?

Thanks in advance,

James

private works for structs the same as it does for classes.
https://dlang.org/spec/attribute.html#visibility_attributes

Perhaps you tried it, realized you could still access it within the same module, and concluded that it didn't work? Consider note #2 at that link: "Symbols with private visibility can only be accessed from within the same module." Import the struct into another module and test the visibility there and you'll get the behavior you're looking for.

Hej JFondren,

Wow, thanks for the quick response. I had read that about the modules ...
but as my test example had failed, I thought that I had misunderstood
the larger picture.

Based on you kind reply, I went back over my example and found that I
had been deceiving myself.

With a quick fix-up edit, it indeed is working as your explanation.

Now, I proceed onto the trickier part of my endeavor ...

Thanks again, and Best Regards,
James

(Sorry for the noise...)

August 08, 2021
On 8/8/21 3:11 AM, james.p.leblanc wrote:
> Hello All.
> 
> Is there a standard way to protect a field of a struct after
> the struct has been initialized?
> 
> Is this possible with a struct?
> 
> If not, I suppose a class (object) would be needed?  If so,
> are there any simple pointers to an example of this?
> 
> Thanks in advance,
> 
> James
> 

I understand your question differently from jfondren. You may be looking for a 'const' (or 'immutable') member:

struct S {
  const int i;

  this(int i) {
    // This will work because "first assignment is initialization"
    this.i = i;
  }
}

void main() {
  auto s = S(42);

  // This won't work
  s.i = 43;

  // This won't work either
  s = S(44);
}

Ali

August 08, 2021
On Sunday, 8 August 2021 at 10:40:51 UTC, Ali Çehreli wrote:

>
> I understand your question differently from jfondren. You may be looking for a 'const' (or 'immutable') member:
>
> struct S {
>   const int i;
>
>   this(int i) {
>     // This will work because "first assignment is initialization"
>     this.i = i;
>   }
> }
>
> void main() {
>   auto s = S(42);
>
>   // This won't work
>   s.i = 43;
>
>   // This won't work either
>   s = S(44);
> }
>
> Ali

Hello Again Ali,

Excellent!  I had tried (an erroneous) variant of this idea earlier ... but
also failed with my attempt.

I am appreciating very much the example you have provided.  I will try
this approach as well for the problem I am working on.  (Some details on
my path forward remain unclear ...)

Best Regards,
James