On Saturday, 23 March 2024 at 21:59:57 UTC, Nick Treleaven wrote:
On Saturday, 23 March 2024 at 21:53:43 UTC, Jonathan M Davis
wrote:
Yes, it's a bug. It's a clear violation of the type system if
a non-mutable variable is ever given a value more than once.
It should be initialized, and then it
On Saturday, 23 March 2024 at 21:53:43 UTC, Jonathan M Davis
wrote:
Yes, it's a bug. It's a clear violation of the type system if a
non-mutable variable is ever given a value more than once. It
should be initialized, and then it should be treated as illegal
to ever assign to it - or to do
On Saturday, March 23, 2024 3:23:23 PM MDT Nick Treleaven via Digitalmars-d-
learn wrote:
> I've not used static constructors before, but it seems like the
> following should not be allowed:
>
> ```d
> import std.stdio;
>
> immutable int x;
>
> @safe shared static
I've not used static constructors before, but it seems like the
following should not be allowed:
```d
import std.stdio;
immutable int x;
@safe shared static this()
{
x.writeln(); // 0
x = 5;
x.writeln(); // 5
x = 6;
x++;
assert(x == 7);
}
```
Should I file a bug
On Saturday, March 23, 2024 12:11:15 AM MDT Per Nordlöw via Digitalmars-d-
learn wrote:
> Why doesn't string implicitly convert to immutable(ubyte)[] in
> @safe mode?
Why would it? They're different types. Their elements happen to have the
same size, but that doesn't mean that they'r
immutable table. This code currently happily compiles:
```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}
void main()
{
import std.stdio;
ubyte[] arr = ['a', 'b', 'c'];
auto t = test(arr);
writeln(t);
arr[0] = 'x';
writeln(t
On Wednesday, 14 February 2024 at 10:57:42 UTC, RazvanN wrote:
This has already been fixed, you just need to use
-preview=fixImmutableConv. This was put behind a preview flag
as it introduces a breaking change.
I just tried that flag on run.dlang.org, and although it fixes
the case I
On Tuesday, 13 February 2024 at 14:05:03 UTC, Johan wrote:
On Tuesday, 13 February 2024 at 08:10:20 UTC, Jonathan M Davis
wrote:
So, there's definitely a bug here, but it's a dmd bug. Its
checks for whether it can safely change the constness of the
return type apparently aren't sophisticated
.
Some test cases: https://d.godbolt.org/z/K1fjdj76M
```d
ubyte[] pure_ubyte(ubyte[] arr) pure @safe;
ubyte[] pure_void(void[] arr) pure @safe;
ubyte[] pure_int(int[] arr) pure @safe;
int[] pure_ubyte_to_int(ubyte[] arr) pure @safe;
// All cases below should not compile, yet some do.
immutable(ubyte
it typed as a UTF string.
> > ubyte becomes char, ushort becomes wchar and uint becomes
> > dchar. Type qualifiers are preserved.
>
> The declaration:
>
> ```d
> auto assumeUTF(T)(T[] arr)
> if (staticIndexOf!(immutable T, immutable ubyte, immutable
> ushort, immut
.
The declaration:
```d
auto assumeUTF(T)(T[] arr)
if (staticIndexOf!(immutable T, immutable ubyte, immutable
ushort, immutable uint) != -1)
```
Shouldn't that precondition's `immutable T` be simply `T`?
As it stands, I can do this with no complaints from the
compiler...
```d
string test(ubyte
On Thursday, 13 July 2023 at 11:55:17 UTC, Ki Rill wrote:
Why does the first example `class A` work, but the second one
with `class B` does not?
```D
class A {
immutable int a;
this(in int a) {
this.a = a;
}
}
class B {
immutable int[] b;
this(in int[] b
On Thursday, 13 July 2023 at 11:55:17 UTC, Ki Rill wrote:
Why does the first example `class A` work, but the second one
with `class B` does not?
```D
class A {
immutable int a;
this(in int a) {
this.a = a;
}
}
class B {
immutable int[] b;
this(in int[] b
Why does the first example `class A` work, but the second one
with `class B` does not?
```D
class A {
immutable int a;
this(in int a) {
this.a = a;
}
}
class B {
immutable int[] b;
this(in int[] b) {
this.b = b;
}
}
void main()
{
auto a = new A(1
Tengo una duda y es que en la documentacion de std.json hay un
ejemplo de codigo que por identidicador ponen "immutable", nose
para que sirve o de que trata. :( alguien me diga porfis :)
On Wednesday, 31 May 2023 at 09:14:49 UTC, Dom DiSc wrote:
On Wednesday, 31 May 2023 at 03:29:33 UTC, Cecil Ward wrote:
I have to admit that I don’t really understand immutable. I
have an idea that it could mean that an object has an address
in ROM, so its value will never change. Maybe const
On Tuesday, 30 May 2023 at 04:11:00 UTC, Cecil Ward wrote:
static immutable T foo;
T bar() {
return foo;
}
Should we get an error from the D compiler here as the
initialiser has been forgotten? What do you think ?
No.
There are no un-initialized values in D.
It gets its default value
On Wednesday, 31 May 2023 at 03:29:33 UTC, Cecil Ward wrote:
I have to admit that I don’t really understand immutable. I
have an idea that it could mean that an object has an address
in ROM, so its value will never change. Maybe const doesn’t
give you such a strong guarantee, disallows ‘you
On Wednesday, 31 May 2023 at 03:23:01 UTC, Cecil Ward wrote:
On Tuesday, 30 May 2023 at 04:15:22 UTC, Ali Çehreli wrote:
On 5/29/23 19:57, Cecil Ward wrote:
> I wish to have one routine
> that can be called with either immutable or (possibly)
mutable argument
> values.
'const' sh
On Tuesday, 30 May 2023 at 04:15:22 UTC, Ali Çehreli wrote:
On 5/29/23 19:57, Cecil Ward wrote:
> I wish to have one routine
> that can be called with either immutable or (possibly)
mutable argument
> values.
'const' should take both immutable and mutable. Can you show
your case wit
On 5/29/23 10:57 PM, Cecil Ward wrote:
I have often come into difficulties where I wish to have one routine
that can be called with either immutable or (possibly) mutable argument
values. The argument(s) in question are in, readonly, passed by value or
passed by const reference. Anyway, no one
On 5/29/23 19:57, Cecil Ward wrote:
> I wish to have one routine
> that can be called with either immutable or (possibly) mutable argument
> values.
'const' should take both immutable and mutable. Can you show your case
with a short example?
> Could I make the one routine int
On Tuesday, 30 May 2023 at 02:57:52 UTC, Cecil Ward wrote:
I have often come into difficulties where I wish to have one
routine that can be called with either immutable or (possibly)
mutable argument values. The argument(s) in question are in,
readonly, passed by value or passed by const
I have often come into difficulties where I wish to have one
routine that can be called with either immutable or (possibly)
mutable argument values. The argument(s) in question are in,
readonly, passed by value or passed by const reference. Anyway,
no one is trying to write to the items passed
Awesome, Thank both of you!
```
enum a = ["A", "B"];
writeln(a);
writeln(aliasSeqOf!a);
writeln([aliasSeqOf!a]);
```
On Sun, Feb 19, 2023 at 11:08:34AM +, realhet via Digitalmars-d-learn wrote:
> Hello,
>
> Is there a better way to transform a string array to a tuple or to an
> AliasSeq?
>
> ```
> mixin(customSyntaxPrefixes.format!`tuple(%(%s,%))`)
> ```
>
> I'd like to use this as variable length
On Sunday, 19 February 2023 at 11:08:34 UTC, realhet wrote:
Is there a better way to transform a string array to a tuple or
to an AliasSeq?
```
mixin(customSyntaxPrefixes.format!`tuple(%(%s,%))`)
```
https://dlang.org/phobos/std_meta.html#aliasSeqOf
Hello,
Is there a better way to transform a string array to a tuple or
to an AliasSeq?
```
mixin(customSyntaxPrefixes.format!`tuple(%(%s,%))`)
```
I'd like to use this as variable length arguments passed to the
startsWith() std function (as multiple needles).
onlineapp.d(3): Error: cannot use non-constant CTFE pointer in
an initializer `cast(immutable(char)*)TEST`
```
Maybe try putting `__gshared bin_ptr = TEST.ptr;` inside a
`shared static this(){}`?
I mean, write it like:
```d
__gshared bin_ptr;
shared static this()
{
bin_ptr = TEST.ptr
pointer in
an initializer `cast(immutable(char)*)TEST`
```
Maybe try putting `__gshared bin_ptr = TEST.ptr;` inside a
`shared static this(){}`?
I mean, write it like:
```d
__gshared bin_ptr;
shared static this()
{
bin_ptr = TEST.ptr;
}
__gshared const TEST = import(`onlineapp.d
how to work this around.
```d
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main(){
__gshared bin_ptr = TEST.ptr;
}
```
```sh
dmd2 -betterC -J. onlineapp.d
onlineapp.d(3): Error: cannot use non-constant CTFE pointer in an
initializer `cast(immutable(char)*)TEST`
```
On Mon, Apr 18, 2022 at 12:55:26PM +, wjoe via Digitalmars-d-learn wrote:
> On Sunday, 17 April 2022 at 14:14:37 UTC, H. S. Teoh wrote:
> > Not entirely true. See paragraph 3 in:
> >
> > https://dlang.org/spec/unittest.html
> >
> > and 10.24.11.3 in:
> >
> >
On Sunday, 17 April 2022 at 14:14:37 UTC, H. S. Teoh wrote:
Not entirely true. See paragraph 3 in:
https://dlang.org/spec/unittest.html
and 10.24.11.3 in:
https://dlang.org/spec/expression.html#assert_expressions
T
Thanks. Either I missed that the last time I checked or it
On 17.04.22 15:27, H. S. Teoh wrote:
On Sun, Apr 17, 2022 at 01:06:36PM +, wjoe via Digitalmars-d-learn wrote:
[...]
On the matter of undefined behavior. Technically a program is in
undefined behavior land after throwing an error, thus every unittest
that continues after assertThrown is
On Sun, Apr 17, 2022 at 04:09:12PM +0200, ag0aep6g via Digitalmars-d-learn
wrote:
[...]
> Failing asserts are a messy part of the language. They are supposed to
> be:
>
> 1) not catchable, because they indicate a bug in the program;
> 2) catchable in order to be testable;
> 3) assumed impossible
`immutable` data is not messy. It's simply not allowed.
On Sun, Apr 17, 2022 at 01:06:36PM +, wjoe via Digitalmars-d-learn wrote:
[...]
> On the matter of undefined behavior. Technically a program is in
> undefined behavior land after throwing an error, thus every unittest
> that continues after assertThrown is therefore nonsense code, is it
> not
On Thursday, 14 April 2022 at 12:10:04 UTC, ag0aep6g wrote:
On 14.04.22 13:42, wjoe wrote:
Undefined behavior yes, but regardless the example proves it
can be done in @system code.
A few versions ago, possibly due to a bug or regression, the
compiler didn't complain in @safe code either.
Of
On 14.04.22 13:42, wjoe wrote:
Undefined behavior yes, but regardless the example proves it can be done
in @system code.
A few versions ago, possibly due to a bug or regression, the compiler
didn't complain in @safe code either.
Of course you are correct academically. However, since it's
regarding const, immutable and const 2.
On Tuesday, 12 April 2022 at 22:23:18 UTC, ag0aep6g wrote:
On Tuesday, 12 April 2022 at 19:54:13 UTC, wjoe wrote:
Especially since it's only a promise and the compiler accepts
this:
void foo (const(char)[] arr)
{
cast(char[])arr[0..3] = "baz";
}
string bar = "123";
foo(bar);
re is a GC, and (2) characters in a string
are immutable.
Without (1), you will end up with either a memory leak or a dangling
pointer; without (2), your slice may randomly mutate when you don't
expect it to.
T
--
May you live all the days of your life. -- Jonathan Swift
fileName;
> report();
>}
>
>~this() { report(); }
>
>void report(string func = __FUNCTION__) {
> import std.stdio;
> writefln!"%s\nworking with %s"(func, fileName);
>}
> }
> alias T1 = const(char)[];
> alias T2 = const
%s"(func, fileName);
}
}
alias T1 = const(char)[];
alias T2 = const char[];
alias T3 = const(char[]); // T3 == T2
alias T4 = immutable char[]; // Not compiling!
void main() {
auto fileName = "foo.txt".dup;
auto s = S!T1(fileName);
fileName[0..3] = "bar";
}/* Results:
*
On 4/12/22 12:54, wjoe wrote:
> I.e. immutable is constant data which is created at compile time - like
> laws of physics,
For completeness, we already have 'enum' and 'static const' for that.
> should get a better name - maybe 'in' and get rid of const.
Yes! 'in' for param
On Tuesday, 12 April 2022 at 19:54:13 UTC, wjoe wrote:
Especially since it's only a promise and the compiler accepts
this:
void foo (const(char)[] arr)
{
cast(char[])arr[0..3] = "baz";
}
string bar = "123";
foo(bar);
assert(bar=="baz");
But I could cast away const and modify the string bar.
f
ROM.)
I was thinking during compile time. By initializing a variable
with immutable data or a pointer that points to an address e.G.
an EEPROM.
Even 'const' cause confusions because it's used in at least two
different ways (even e.g. in C++):
1) I will not mutate data through this ref
>
>> 2) This variable is const:
>>
>> const i = 42;
>>
>> Well, there is the confusion: There is no "reference" in the second
>> case at all!
> I think this second case should not be allowed. Use
>
> immutable i = 42;
>
> instead. The mea
: There is no "reference" in the
second case at all!
I think this second case should not be allowed. Use
immutable i = 42;
instead. The meaning is identical, but we could remove the burden
of two different meanings from const if it is not allowed. const
should only be allowed in function de
On 4/11/22 05:57, wjoe wrote:
> To my understanding immutable data should reside in a separate data
> segment which itself could reside in ROM.
We are getting into implementation details which a programming language
acts as not to care (but has to do especially when it's a system
progr
On 4/11/22 08:02, Paul Backus wrote:
> any pointers or references
To add, Salih and I were in an earlier discussion where that concept
appeared as "indirections."
Ali
like this.
```d
struct S
{
. . .
string toString() { return ""; }
}
//S test(inout S s)/*
S test(S s)//*/
{
s.i = 2;
return s;
}
void main()
{
immutable s = S(1);
test(s).writeln;
"Hello".writefln!"%s D!";
}
```
If the inout is set, it does not allow c
On Monday, 11 April 2022 at 03:24:11 UTC, Ali Çehreli wrote:
On 4/10/22 20:05, norm wrote:
> On Sunday, 10 April 2022 at 23:19:47 UTC, rikki cattermole
wrote:
> In my mind immutable data
> means the data will not change and neither will the result of
reading
> that data, ever.
Yes
s;
}
void main()
{
immutable s = S(1);
test(s).writeln;
"Hello".writefln!"%s D!";
}
```
If the inout is set, it does not allow compilation.
Thanks, SDB79
On Sunday, 10 April 2022 at 23:05:24 UTC, norm wrote:
Hi All,
I am clearly misunderstanding something fundamental, and
probably obvious :D
Reading some of the discussions on __metadata I was wondering
if someone could explain why a immutable reference counting
type is needed. By definition
On Sunday, 10 April 2022 at 23:19:47 UTC, rikki cattermole wrote:
immutable isn't tied to lifetime semantics.
It only says that this memory will never be modified by anyone
during its lifetime.
Anyway, the real problem is with const. Both mutable and
immutable become it automatically.
I
Storage classes like immutable/const/shared are not tied to any memory
management strategy. Nor does it dictate memory lifetime.
It only dictates how it can be interacted with when you have a reference
to it.
On 4/10/22 20:05, norm wrote:
> On Sunday, 10 April 2022 at 23:19:47 UTC, rikki cattermole wrote:
> In my mind immutable data
> means the data will not change and neither will the result of reading
> that data, ever.
Yes.
> I don't get how you can have thread safety g
On Sunday, 10 April 2022 at 23:19:47 UTC, rikki cattermole wrote:
immutable isn't tied to lifetime semantics.
It only says that this memory will never be modified by anyone
during its lifetime.
This is clearly where I am misunderstanding. In my mind immutable
data means the data
immutable isn't tied to lifetime semantics.
It only says that this memory will never be modified by anyone during
its lifetime.
Anyway, the real problem is with const. Both mutable and immutable
become it automatically.
Hi All,
I am clearly misunderstanding something fundamental, and probably
obvious :D
Reading some of the discussions on __metadata I was wondering if
someone could explain why a immutable reference counting type is
needed. By definition a reference counter cannot be immutable, so
what
On Tuesday, 29 March 2022 at 18:59:41 UTC, H. S. Teoh wrote:
On Tue, Mar 29, 2022 at 05:58:11PM +, Fruitful Approach via
Digitalmars-d-learn wrote:
[...]
1) `immutable immutable(Prop)[]` is identical to
`immutable(Prop[])`.
Immutable is transitive. There is no need to spell
On Tuesday, 29 March 2022 at 19:26:51 UTC, Ali Çehreli wrote:
Better yet, and as I know you know :), and as it comes up
occasionally but I usually forget in my own code; 'in' is much
better than 'const' on function parameters because it has super
powers when compiled with -preview=in:
Nope! 'const' is replaced with
'auto' instantly. :)
'const' and 'immutable' on member variables are trouble because they
make objects unassignable. (But you said 'class', so there is no such
issue with them in D anyway.) But is that too bad? Is assignment
overrated anyway? I don't know... :/
Ali
On 3/29/22 11:59, H. S. Teoh wrote:
> As a general principle, const should be used when you're on the
> receiving end of data that should not be changed (e.g., function
> parameters)
Better yet, and as I know you know :), and as it comes up occasionally
but I usually forget in my own code;
On Tue, Mar 29, 2022 at 05:58:11PM +, Fruitful Approach via
Digitalmars-d-learn wrote:
> I have immutable members:
>
> `immutable immutable(Prop)[] axioms` which I can't initialize with
> Prop[], so I call this "immutable-poisoning" of the rest of my code.
> Can you
I have immutable members:
`immutable immutable(Prop)[] axioms` which I can't initialize
with Prop[], so I call this "immutable-poisoning" of the rest of
my code. Can you provide a 10 line example of how to best work
with immutable types, specifically immutable members, together
On Saturday, 18 December 2021 at 12:50:17 UTC, Tejas wrote:
As Ali said, this is an implementation issue.
So I guess the answer to your question is that this is a bug.
Please file a report at [issues.dlang.org](issues.dlang.org)
Looks like this is same case:
On Saturday, 18 December 2021 at 11:01:53 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote:
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
```
Interesting what discussed behaviour isn't affects method what
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote:
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
```
Interesting what discussed behaviour isn't affects method what
implements same functionality as dtor and called explictly at
each
On Friday, 17 December 2021 at 18:51:56 UTC, Ali Çehreli wrote:
On 12/17/21 10:01 AM, Tejas wrote:
> [...]
Storage,
There is no such requirement nor guarantee.
[...]
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
void main()
{
immutabl
On 12/17/21 10:01 AM, Tejas wrote:
> I think since `immutable` objects are kept in Read Only Storage,
There is no such requirement nor guarantee.
> you
> can't call destructors on them
Destructor is nothing but a piece of code that is executed when an
object's life ends. A destru
On Friday, 17 December 2021 at 18:32:43 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error: `immutable` method `serializer_bug.S.~this` is not
callable using
On Friday, 17 December 2021 at 18:19:34 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means &q
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means "not mutable for whole its lifetime"
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
[...]
("serializer_bug" is just name of my local .d file)
I think since
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serialize
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serializer_bug" is just name of my local .d file)
```d
/+ dub.json:
{
"name": "test",
"dependencies": {
}
}
+/
struct S
{
~this() {}
}
immutable class Imm
{
S s; // this is immutable value because whole class is
immutable
this()
{
s = S();
}
~this() {} // Comment out this
On Friday, 19 November 2021 at 17:38:53 UTC, Merlin Diavova wrote:
I'm trying to figure out the most efficient way to create
modified instances of immutable structs.
This might not be the best way but it is a kinda cool trick
anyway: structs have a `tupleof` property you can slice. So you
Hi all,
I'm trying to figure out the most efficient way to create
modified instances of immutable structs.
Currently, I'm doing the following:
```d
immutable struct Node {
string label;
Node parentNode;
NetworkPort port;
auto withLabel(string newLabel
On Thursday, 2 September 2021 at 23:12:28 UTC, Steven
Schveighoffer wrote:
[...]
immutable means "I can never change and *everything I point at*
can never change".
[...]
If that is how the language defines the keyword 'immutable' when
used in the definition of a pointer variabl
On 9/2/21 9:01 AM, DLearner wrote:
Suppose there is a variable that is set once per run, and is (supposed)
never to be altered again.
An accessor function can be a solution, which supports your other
comment about data potentially mutating by other means:
// Assume these are in a module
//
On 9/2/21 1:17 PM, DLearner wrote:
I am looking for a mutable Arr but would like an immutable ArrPtr.
Then you want const not immutable.
Here is the reason:
```d
void main()
{
int x = 5;
immutable int *ptr = cast(immutable int *)
assert(*ptr == 5); // ok
x = 6;
assert
On Thu, Sep 02, 2021 at 05:17:15PM +, DLearner via Digitalmars-d-learn
wrote:
[...]
> The following clean-compiled and produced the expected result:
> ```
> ubyte[10] Arr;
>
> immutable void* ArrPtr;
> shared static this() {
> ArrPtr = cas
On Thursday, 2 September 2021 at 17:17:15 UTC, DLearner wrote:
Surely there is no inconsistency - at run time the array is in
a fixed place, so ArrPtr is (or at least should be) a
constant, but the contents of the array
can vary as the program runs.
In the case of `immutable(T)* ArrPtr
If you want only address, you can keep it as size_t:
ubyte[10] Arr;
immutable size_t Address;
static this() {
Address = cast(size_t)([0]);
}
, variable is 'ArrPtr';
```
ubyte[10] Arr;
// immutable void* ArrPtr;
void* ArrPtr;
void main() {
ArrPtr = cast(void*)Arr[0];
// modify ArrPtr>
}
```
Is there a way of getting D to guarantee that ArrPtr is never
modified after
```
ArrPtr = cast(void*)Arr[0];
```]
You should
On 9/2/21 12:01 PM, DLearner wrote:
Suppose there is a variable that is set once per run, and is (supposed)
never to be altered again. However, the value to which it is set is not
known at compile time.
Example below, variable is 'ArrPtr';
```
ubyte[10] Arr;
// immutable void* ArrPtr;
void
use case of `immutable`. Using the example you
gave, you'd move the initialization of ArrPtr into a static module
constructor:
immutable void* ArrPtr;
shared static this() {
ArrPtr = ...; // initialize it here
}
void main() {
... // ArrPtr is
Suppose there is a variable that is set once per run, and is
(supposed) never to be altered again. However, the value to
which it is set is not known at compile time.
Example below, variable is 'ArrPtr';
```
ubyte[10] Arr;
// immutable void* ArrPtr;
void* ArrPtr;
void main() {
ArrPtr
On Sunday, 18 July 2021 at 10:02:07 UTC, ag0aep6g wrote:
On 17.07.21 15:56, ag0aep6g wrote:
+1.
IMO,`strong pure` is `the outside world` has no impact on me.
`Funcs` don't have any `indirect`.
On 17.07.21 15:56, ag0aep6g wrote:
At a glance, the only meaningful use of `PURE.strong` seems to be in
dcast.d, introduced by the PR you linked. Changing that to `PURE.const_`
doesn't break any tests for me. So I'm inclined to believe that
`PURE.strong` is nonsense, and that `PURE.const_`
On 17.07.21 14:56, Dennis wrote:
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec says: "A
strongly pure function has no parameters with mutable i
On 18/07/2021 12:56 AM, Dennis wrote:
I don't know whether the spec or code is correct.
Unless otherwise specified, the code is authoritative.
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec
says: "A strongly pure function has no parameters with mutable
indirections" [1].
I just took
On 17.07.21 13:05, Dennis wrote:
There used to be a complex `isReturnIsolated` check, but the [fix for
issue 15660](https://github.com/dlang/dmd/pull/8048) reduced it to a
check 'is the function strongly `pure`' which means 'parameters are
values or immutable'. To reduce code breakage
On Saturday, 17 July 2021 at 05:44:24 UTC, ag0aep6g wrote:
I tried doing that, but `-preview=dip1000` causes trouble. This
fails:
(...)
I'm not sure what's going on.
I'm not completely caught up, but from what I see, pure and
immutable have a history of issues:
[Issue 11503 - Type system
On 17.07.21 00:27, H. S. Teoh wrote:
Hmm, OK. Not sure why .array isn't being inferred as unique... but yeah,
you probably have to resort to using @trusted with .assumeUnique.
In addition to `pure`, you also need a const/immutable input and a
mutable output, so that the output cannot
1 - 100 of 1399 matches
Mail list logo
