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:
> >
> > https://dlang.org/spec/ex
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 ther
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
On 17.04.22 15:06, wjoe 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 ?
Yes.
Failing asserts are a messy part of the language.
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 c
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 possi
On Tuesday, 12 April 2022 at 23:23:59 UTC, Ali Çehreli wrote:
[...]
Looking at this from a technical perspective - everything you say
is true - and thanks for clearing up some of my confusion in that
department.
Looking at this from a natural language (English) perspective -
words prompt i
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);
assert(bar=="baz
On Wed, Apr 13, 2022 at 08:39:17AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 4/12/22 21:34, Salih Dincer wrote:
>
> > I tried the following and I didn't understand one thing: Why is
> > there no need to use dup when slicing?
[...]
Because of two things: (1) there is a GC, and (2) ch
On 4/12/22 21:34, Salih Dincer wrote:
> I tried the following and I didn't understand one thing: Why is there no
> need to use dup when slicing?
I don't think I understand you fully.
> ```d
> struct S(T) {
> T fileName;
>
>this(T fileName) {
> this.fileName = fileName;
> report(
On Monday, 11 April 2022 at 21:48:56 UTC, Ali Çehreli wrote:
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
I tried the following and I didn't understand one thing: Why i
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 parameters! :D
>> import
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.
On Monday, 11 April 2022 at 22:10:07 UTC, Ali Çehreli wrote:
On 4/11/22 05:57, wjoe wrote:
> And because the data could be
> in ROM any modification is an error.
Fully agreed. However, how could I initialize such an object
then? (You may have meant a read-only memory page instead of
ROM.)
On 4/12/22 03:28, Dom DiSc wrote:
> On Monday, 11 April 2022 at 22:10:07 UTC, Ali Çehreli wrote:
>> 1) I will not mutate data through this reference. For example, a
>> parameter that is pointer to const achieves that:
>>
>> void foo (const(int)[] arr);
>>
>> 2) This variable is const:
>>
>> co
On Monday, 11 April 2022 at 22:10:07 UTC, Ali Çehreli wrote:
1) I will not mutate data through this reference. For example,
a parameter that is pointer to const achieves that:
void foo (const(int)[] arr);
2) This variable is const:
const i = 42;
Well, there is the confusion: There is no
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
programming l
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
On Monday, 11 April 2022 at 12:12:39 UTC, Salih Dincer wrote:
It worked for me in a different way.
1 is (about to be) alive!
2 is (already) dead.
2 is (already) dead.
2 is (already) dead.
2 is (already) dead.
2 is (already) dead.
Hello D!
1 is (already) dead.
Because I changed the code lik
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.
> I don't g
On Monday, 11 April 2022 at 03:24:11 UTC, Ali Çehreli wrote:
The output:
0 is (about to be) alive!
0 is (already) dead.
1 is (about to be) alive!
1 is (already) dead.
2 is (about to be) alive!
2 is (already) dead.
It worked for me in a different way.
1 is (about to be) alive!
2 is (already
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 w
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 guarantees based on immutabl
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 will not ch
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 would
30 matches
Mail list logo
