On Wednesday, 13 February 2019 at 16:40:18 UTC, H. S. Teoh wrote:
So ironically, the iron-clad semantics of D's const system
turns out to be also its own downfall.
Such things are not ironic. There is always a trade off. You get
nothing for free in this universe. Physics tells us this.
On Saturday, 22 June 2019 at 05:10:14 UTC, Yatheendra wrote:
It feels disingenous to want to call a caching object even
"logically" const. There has to be a scaffolding-based but
hopefully generic compromise. I haven't yet tested this belief,
but I believe "physical" const is of good use
It feels disingenous to want to call a caching object even
"logically" const. There has to be a scaffolding-based but
hopefully generic compromise. I haven't yet tested this belief,
but I believe "physical" const is of good use wherever it can be
applied.
On Friday, 21 June 2019 at 23:39:20
On Fri, Jun 21, 2019 at 06:32:33PM +, Yatheendra via Digitalmars-d-learn
wrote:
[...]
>struct CostlyComputeResult {
> ... // data fields
> // constructor takes compute results, no postblit
>}
>
>struct Wrapper {
> const (CostlyComputeResult) *cachee = 0;
>
That is a comprehensive reply. No pointers to other material
required :-)
On Friday, 21 June 2019 at 16:35:50 UTC, H. S. Teoh wrote:
On Fri, Jun 21, 2019 at 06:07:59AM +, Yatheendra via
Digitalmars-d-learn wrote:
Actually, optimizers work best when there is minimal mutation
*in the
On Fri, Jun 21, 2019 at 06:07:59AM +, Yatheendra via Digitalmars-d-learn
wrote:
> Am I mistaken in saying that we are conflating:
>"anything that is logically const should be declared const"
No, not in D. D does not have logical const; it has "physical" const,
which is a strict subset
Am I mistaken in saying that we are conflating:
"anything that is logically const should be declared const"
// makes perfect sense
// e.g. the lowest 2, and some branches of the 3rd and 4th,
levels
// of members (and a subset of the overall methods) in a
5-deep type hierarchy are
On 20.02.2019 11:05, Kagamin wrote:
On Tuesday, 19 February 2019 at 16:38:17 UTC, drug wrote:
The same I can say about properties - for example I use them in meta
programming to detect what to serialize/process - I skip methods but
serialize properties and for me this is a nice language
On Tuesday, 19 February 2019 at 16:38:17 UTC, drug wrote:
The same I can say about properties - for example I use them in
meta programming to detect what to serialize/process - I skip
methods but serialize properties and for me this is a nice
language feature.
Serialization of arbitrary
On 19.02.2019 19:19, Kagamin wrote:
On Tuesday, 19 February 2019 at 15:30:22 UTC, Atila Neves wrote:
I keep hearing how const is nigh unusable in D, and except for ranges
I litter my code with const everywhere, pretty much just as often as I
used in C++.
I once spent a good amount of effort
On Tuesday, 19 February 2019 at 15:30:22 UTC, Atila Neves wrote:
I keep hearing how const is nigh unusable in D, and except for
ranges I litter my code with const everywhere, pretty much just
as often as I used in C++.
I once spent a good amount of effort to annotate my code with
pure and
On Wednesday, 13 February 2019 at 16:40:18 UTC, H. S. Teoh wrote:
On Wed, Feb 13, 2019 at 11:32:46AM +, envoid via
Digitalmars-d-learn wrote:
[...]
Const in D is very restrictive because it's supposed to provide
real compiler guarantees, i.e., it's statically verifiable that
the data
On Wednesday, 13 February 2019 at 16:40:18 UTC, H. S. Teoh wrote:
On Wed, Feb 13, 2019 at 11:32:46AM +, envoid via
Digitalmars-d-learn wrote:
Unfortunately, that guarantee also excludes a lot of otherwise
useful idioms, like objects that cache data -- a const object
cannot cache data
Thank you for such a comprehensive answer.
On Wednesday, 13 February 2019 at 11:32:46 UTC, envoid wrote:
Is there an article that explains best practices of using const
in D?
You can find some information here:
https://dlang.org/articles/const-faq.html
> course, it's not perfect but one can document their intentions and
> it's possible to use synchronization primitives without an issue. On
> the opposite side, D has a stricter (transitive) const and it's almost
> useless in many cases. Is there an article that explains best
> pract
On Wednesday, 13 February 2019 at 11:32:46 UTC, envoid wrote:
Is there an article that explains best practices of using const
in D?
Chapter 8 of Andrei Alexandrescu's book The D Programming
Language.
On Wednesday, 13 February 2019 at 11:32:46 UTC, envoid wrote:
Is there an article that explains best practices of using const
in D?
http://jmdavisprog.com/articles/why-const-sucks.html
D has immutable data, const allows to consume both mutable and
immutable data.
synchronization primitives
without an issue. On the opposite side, D has a stricter
(transitive) const and it's almost useless in many cases. Is
there an article that explains best practices of using const in
D? The statement "In C++ const isn't transitive so we fixed
that." alone isn't
20 matches
Mail list logo
