On Monday, 29 September 2014 at 00:51:26 UTC, Walter Bright wrote:
On 9/28/2014 5:38 PM, Manu via Digitalmars-d wrote:
That said, my friend encountered one of my frequently
recurring pain
cases himself yesterday:
struct S(T...)
{
void f(T args) {}
}
S!(int, ref S) fail; // -- no clean way
On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr wrote:
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right that tuples in D cannot contain storage classes
void foo(ref int x){}
alias p=ParameterTypeTuple!foo;
pragma(msg, p); // (ref int)
(But this does not help.)
Well, only
On 30 September 2014 16:06, Daniel N via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr wrote:
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right that tuples in D cannot contain storage classes
void foo(ref int x){}
alias
On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via
Digitalmars-d wrote:
I have actually thought of that ;) ... but I tend to think that
only D
users present on this forum are likely to make sense of that
code, and
why.
You can probably wrap this in a nice library solution with an
On Tuesday, 30 September 2014 at 07:18:20 UTC, deadalnix wrote:
On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via
Digitalmars-d wrote:
I have actually thought of that ;) ... but I tend to think
that only D
users present on this forum are likely to make sense of that
code, and
why.
You
On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
Also, inferring everything is quite
expensive and we want D to compile fast.
Doesn't the compiler have to do that anyway?
I'd expect a proper compiler to check if my code is actually what
I claim it is. It's quite easy to mark
Otherwise if you like D, then try to
improve it from the inside, writing dmd/Phobos/druntime pull
requests,
instead of doing it from the outside.
I'd never have my PR's pulled.
I'm also not as interested in language development as it might
appear.
I'm interested in writing code and getting
On Tuesday, 30 September 2014 at 00:03:40 UTC, Manu via
Digitalmars-d wrote:
I've affected all of the change that I am capable of, and I
need to
decide if I'm happy with D as is, or not, rather than maintain
my
ambient frustration that it's sitting at 99%, with the last 1%
unattainable to me
ixid:
It might be an effective argument to give bearophile some of
the problematic code and see what his idiomatic D version looks
like and if what you're after is elegantly achievable.
Manu is quite more expert than me in the kind of code he writes.
So what you propose is just going to
On Tuesday, 30 September 2014 at 11:45:37 UTC, Ola Fosheim
Grøstad wrote:
(it is only pointers after all).
Semi-tangential to this discussion, but this bit hits on
something I've been thinking for a little while... ref is, at its
core, trying to be a non-nullable pointer. And I get the
On Tuesday, 30 September 2014 at 09:13:02 UTC, ixid wrote:
Otherwise if you like D, then try to
improve it from the inside, writing dmd/Phobos/druntime pull
requests,
instead of doing it from the outside.
I'd never have my PR's pulled.
I'm also not as interested in language development as
On 9/30/14, 2:13 AM, ixid wrote:
from his POV he's doing something massive to help D while the community
has gone into a negative mode.
Indeed that's an accurate characterization of my POV. -- Andrei
On Tuesday, 30 September 2014 at 13:08:57 UTC, Wyatt wrote:
Semi-tangential to this discussion, but this bit hits on
something I've been thinking for a little while... ref is, at
its core, trying to be a non-nullable pointer. And I get the
strong sense that it's failing at it.
That's a very
On Tuesday, 30 September 2014 at 13:47:22 UTC, John Colvin wrote:
On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via
Digitalmars-d wrote:
On 30 September 2014 16:06, Daniel N via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr
On Tuesday, 30 September 2014 at 07:10:08 UTC, Manu via
Digitalmars-d wrote:
On 30 September 2014 16:06, Daniel N via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 29 September 2014 at 04:23:08 UTC, Timon Gehr wrote:
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right
On Tuesday, 30 September 2014 at 09:13:02 UTC, ixid wrote:
I also suspect Andrei is doing a major project at the moment
which is making him uncharacteristically harsh in his
responses, from his POV he's doing something massive to help D
while the community has gone into a negative mode.
On 9/30/2014 2:13 AM, ixid wrote:
It might be an effective argument to give bearophile some of the
problematic code and see what his idiomatic D version looks like and if
what you're after is elegantly achievable.
Or heck, ask the n.g. Lots of people here are very creative in their
solutions
On Tuesday, 30 September 2014 at 08:33:27 UTC, Trass3r wrote:
On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
Also, inferring everything is quite
expensive and we want D to compile fast.
Doesn't the compiler have to do that anyway?
I'd expect a proper compiler to check if my
On 9/28/14, 5:38 PM, Manu via Digitalmars-d wrote:
I was out of town (was on my phone), and now I'm home with 2 guests,
and we're working together. I can't sit and craft a pile of example
cases until I'm alone and have time to do so. I haven't ignored it,
but I need to find the time to give you
On 29 September 2014 12:43, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/28/2014 6:31 PM, Manu via Digitalmars-d wrote:
S!(int, S*)
That's different.
I feel like I have to somehow justify to you guys how meta code works
in D. I have meta code that is no less
On Monday, 29 September 2014 at 08:02:45 UTC, Andrei Alexandrescu
wrote:
I understand. The short answer to this is D cannot do that and
we cannot afford to change the language to make it do that.
There are two longer answers.
I think this is because ref have several conflated meaning:
- I
On 29 September 2014 18:02, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/28/14, 5:38 PM, Manu via Digitalmars-d wrote:
I was out of town (was on my phone), and now I'm home with 2 guests,
and we're working together. I can't sit and craft a pile of example
Manu:
Trouble for me is, I've invested so much time now.
If your think your choice was the wrong one, don't invest even
more in something you think is wasted effort. Otherwise if you
like D, then try to improve it from the inside, writing
dmd/Phobos/druntime pull requests, instead of doing
On 30 September 2014 09:25, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 29 September 2014 at 08:02:45 UTC, Andrei Alexandrescu
wrote:
I understand. The short answer to this is D cannot do that and we cannot
afford to change the language to make it do that.
On Tuesday, 30 September 2014 at 00:33:08 UTC, Manu via
Digitalmars-d wrote:
I don't see ref that way at all. I see it so much simpler than
that:
ref is a type of pointer. It's effectively T(immutable(*)).
It's uses are emergent from what it is; a good way to pass big
things
around in argument
On 30 September 2014 10:44, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 30 September 2014 at 00:33:08 UTC, Manu via
Digitalmars-d wrote:
I don't see ref that way at all. I see it so much simpler than that:
ref is a type of pointer. It's effectively
On 30 September 2014 10:29, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Manu:
Trouble for me is, I've invested so much time now.
If your think your choice was the wrong one, don't invest even more in
something you think is wasted effort.
It's not to say it's the 'wrong
Manu:
In the case of ref, I can't think of any programmers that I've
introduced to D that haven't complained about ref within their
first
hour or 2 of interaction.
Most of the times I have no problems with D ref. Perhaps you are
trying to use D too much like you use C++.
I'd never have
On Sunday, 28 September 2014 at 04:04:24 UTC, Walter Bright wrote:
On 9/27/2014 8:50 PM, deadalnix wrote:
On Sunday, 28 September 2014 at 03:08:09 UTC, Walter Bright
wrote:
Since the function body is always present, inference should
always be done. It
isn't costly. Should file an enhancement
On 9/27/2014 10:48 PM, deadalnix wrote:
On Sunday, 28 September 2014 at 04:04:24 UTC, Walter Bright wrote:
On 9/27/2014 8:50 PM, deadalnix wrote:
On Sunday, 28 September 2014 at 03:08:09 UTC, Walter Bright wrote:
Since the function body is always present, inference should always be done. It
deadalnix:
the function could be returned and used elsewhere, where these
attribute aren't necessary.
Filed:
https://issues.dlang.org/show_bug.cgi?id=13550
Bye,
bearophile
On 9/28/2014 1:49 AM, bearophile wrote:
Filed:
https://issues.dlang.org/show_bug.cgi?id=13550
Thanks!
On 9/27/14, 7:42 PM, Manu via Digitalmars-d wrote:
void f() pure nothrow @nogc
{
void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
Doesn't complain about pure though.
Is it reasonable to say that the scope of the outer function is
On 28 September 2014 22:21, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/27/14, 7:42 PM, Manu via Digitalmars-d wrote:
void f() pure nothrow @nogc
{
void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
On 9/28/2014 5:38 PM, Manu via Digitalmars-d wrote:
That said, my friend encountered one of my frequently recurring pain
cases himself yesterday:
struct S(T...)
{
void f(T args) {}
}
S!(int, ref S) fail; // -- no clean way to do this. I need this very
frequently, and he reached for it too,
On 29 September 2014 10:51, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/28/2014 5:38 PM, Manu via Digitalmars-d wrote:
That said, my friend encountered one of my frequently recurring pain
cases himself yesterday:
struct S(T...)
{
void f(T args) {}
}
S!(int,
On 9/28/2014 6:31 PM, Manu via Digitalmars-d wrote:
S!(int, S*)
That's different.
I feel like I have to somehow justify to you guys how meta code works
in D. I have meta code that is no less than 5 layers deep. It's
complex, but at the same time, somehow surprisingly elegant and simple
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right that tuples in D cannot contain storage classes
void foo(ref int x){}
alias p=ParameterTypeTuple!foo;
pragma(msg, p); // (ref int)
(But this does not help.)
On 9/28/2014 9:23 PM, Timon Gehr wrote:
On 09/29/2014 04:43 AM, Walter Bright wrote:
You're right that tuples in D cannot contain storage classes
void foo(ref int x){}
alias p=ParameterTypeTuple!foo;
pragma(msg, p); // (ref int)
(But this does not help.)
You're right, I had forgotten
void f() pure nothrow @nogc
{
void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
Doesn't complain about pure though.
Is it reasonable to say that the scope of the outer function is
nothrow+@nogc, and therefore everything declared within should
On Sunday, 28 September 2014 at 02:42:29 UTC, Manu via
Digitalmars-d wrote:
void f() pure nothrow @nogc
{
void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
Doesn't complain about pure though.
Is it reasonable to say that the scope of the
On 9/27/2014 7:56 PM, deadalnix wrote:
On Sunday, 28 September 2014 at 02:42:29 UTC, Manu via Digitalmars-d wrote:
void f() pure nothrow @nogc
{
void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
Doesn't complain about pure though.
Is it
On Sunday, 28 September 2014 at 03:08:09 UTC, Walter Bright wrote:
Since the function body is always present, inference should
always be done. It isn't costly. Should file an enhancement
request on this.
If you have a control flow graph to analyze it can become quite
costly.
On 9/27/2014 8:50 PM, deadalnix wrote:
On Sunday, 28 September 2014 at 03:08:09 UTC, Walter Bright wrote:
Since the function body is always present, inference should always be done. It
isn't costly. Should file an enhancement request on this.
If you have a control flow graph to analyze it can
44 matches
Mail list logo
