On Monday, April 09, 2018 23:58:02 Drone1h via Digitalmars-d-learn wrote:
> On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote:
> > [...]
> > http://jmdavisprog.com/articles/why-const-sucks.html
>
> I have just read the reply and the article.
>
> I cannot believe you have written
On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote:
[...]
http://jmdavisprog.com/articles/why-const-sucks.html
I have just read the reply and the article.
I cannot believe you have written this article in response to
this thread (perhaps I am mis-interpreting the date of the
On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote:
On Monday, March 19, 2018 00:14:11 Drone1h via
Digitalmars-d-learn wrote:
I am not sure whether I can make it work with "inout" instead
of "const". Perhaps I am missing something.
...
May I ask that you confirm that this is what
On Friday, 2 February 2018 at 14:29:34 UTC, H. S. Teoh wrote:
On Fri, Feb 02, 2018 at 07:06:56AM +, Simen Kjærås via
Digitalmars-d-learn wrote:
[...]
Its semantics are not broken; it's just harder to use. Due to
const transitivity, it's an all-or-nothing deal. .tailConst
gives us the
On Monday, March 19, 2018 00:14:11 Drone1h via Digitalmars-d-learn wrote:
> I am not sure whether I can make it work with "inout" instead of
> "const". Perhaps I am missing something.
...
> May I ask that you confirm that this is what you suggested ?
> Thank you.
Marking a empty or front with
First of all, thank you all for the replies. It has taken me some
time to learn a bit more to be able to understand at least some
parts of them. I have a further question below the quotes.
On Tuesday, 30 January 2018 at 01:20:09 UTC, Jonathan M Davis
wrote:
On Tuesday, January 30, 2018
On Friday, 2 February 2018 at 14:29:34 UTC, H. S. Teoh wrote:
Its semantics are not broken; it's just harder to use. Due to
const transitivity, it's an all-or-nothing deal. .tailConst
gives us the middle ground.
If the semantics of const means that users will have to write
.tailConst all
On Fri, Feb 02, 2018 at 07:06:56AM +, Simen Kjærås via Digitalmars-d-learn
wrote:
[...]
> Which code would you rather write?
>
> void foo(T)(const T t) {}
> foo(myValue);
>
> or:
>
> void foo(T)(T t) if (isTailConst!T) {}
> foo(myValue.tailConst);
[...]
More thoughts on this: what if we
On Fri, Feb 02, 2018 at 07:06:56AM +, Simen Kjærås via Digitalmars-d-learn
wrote:
> On Thursday, 1 February 2018 at 18:58:15 UTC, H. S. Teoh wrote:
> > However, if we go back to the idea of tail-const, we could
> > potentially eliminate the need for casts and also avoid breaking
> >
On Thursday, 1 February 2018 at 18:58:15 UTC, H. S. Teoh wrote:
However, if we go back to the idea of tail-const, we could
potentially eliminate the need for casts and also avoid
breaking immutable. Basically, the problem with writing
const(RefCounted!T) is that it's a one-way street: on the
On Thu, Feb 01, 2018 at 07:52:32AM +, Simen Kjærås via Digitalmars-d-learn
wrote:
> On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote:
> > I haven't thought through it carefully, but if .headConst is a
> > viable solution to the head-const problem, then conceivably we could
> >
On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote:
I haven't thought through it carefully, but if .headConst is a
viable solution to the head-const problem, then conceivably we
could also extend it to deal with immutable payloads too. Then
we could go from, say,
On 1/31/18 7:49 PM, Jonathan M Davis wrote:
On Wednesday, January 31, 2018 11:58:38 Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 1/30/18 8:05 PM, Jonathan M Davis wrote:
Except that unless front returns by ref, it really doesn't matter
whether
front is const unless it's violating the
On Wednesday, January 31, 2018 11:58:38 Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/30/18 8:05 PM, Jonathan M Davis wrote:
> > Except that unless front returns by ref, it really doesn't matter
> > whether
> > front is const unless it's violating the range API, since front is
> >
On 1/30/18 8:05 PM, Jonathan M Davis wrote:
Except that unless front returns by ref, it really doesn't matter whether
front is const unless it's violating the range API, since front is supposed
to return the same value until popFront is called (or if it's assigned a new
value via a front that
On Wed, Jan 31, 2018 at 07:08:58AM +, Simen Kjærås via Digitalmars-d-learn
wrote:
> On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote:
> > .headConst
>
> .headMutable. :p Head-const is something we generally want to avoid.
[...]
*facepalm* Yes, .headMutable, not .headConst.
On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote:
.headConst
.headMutable. :p Head-const is something we generally want to
avoid.
--
Simen
On Tue, Jan 30, 2018 at 06:05:47PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Tuesday, January 30, 2018 07:49:28 H. S. Teoh via Digitalmars-d-learn
> wrote:
[...]
> > Simen has had some ideas recently about "head mutable" aka
> > tail-const, which could be a first step towards
On Tuesday, January 30, 2018 07:49:28 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Tue, Jan 30, 2018 at 08:54:00AM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> > On 1/29/18 8:20 PM, Jonathan M Davis wrote:
> [...]
>
> > > If you want to put an attribute on it, inout is better,
On Tue, Jan 30, 2018 at 08:54:00AM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/29/18 8:20 PM, Jonathan M Davis wrote:
[...]
> > If you want to put an attribute on it, inout is better, because then
> > it will work with any constness, but in general, I'd suggest just
> >
On 1/29/18 8:20 PM, Jonathan M Davis wrote:
On Tuesday, January 30, 2018 01:05:54 Drone1h via Digitalmars-d-learn wrote:
Hello all,
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives ("empty",
"front", "popFront") to another
On Tuesday, January 30, 2018 01:05:54 Drone1h via Digitalmars-d-learn wrote:
> Hello all,
>
>
>
> I am trying to implement a ("struct template" ? what is the
> correct word ?) range that just forwards its primitives ("empty",
> "front", "popFront") to another range, possibly with some very
>
Hello all,
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives ("empty",
"front", "popFront") to another range, possibly with some very
limited filtering/alteration, as std.range.Take (just to learn).
Initially, the "front"
23 matches
Mail list logo
