On 09/23/2016 03:39 AM, Martin Nowak wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Bringing up this topic again b/c there was still almost no feedback on
the
On Fri, Sep 23, 2016 at 06:33:52PM +, Martin Nowak via Digitalmars-d wrote:
> On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote:
> > On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
> > Is there any benefit to adding new operator overloading to handle
> > this case,
On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote:
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak
wrote:
Is there any benefit to adding new operator overloading to
handle this case, like a opValueAssign instead of opIndexAssign
?
Maybe, making the two implementations
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
Bringing up this topic again b/c there was still almost no
feedback on the actual plan.
Is there any benefit to adding new operator overloading to handle
this case, like a opValueAssign instead of opIndexAssign ?
On Friday, 23 September 2016 at 07:56:02 UTC, Daniel Kozak wrote:
What is wrong with built-in AAs? And what advantages comes with
library AAs?
http://forum.dlang.org/post/uybkxmjlpswufhiwc...@forum.dlang.org
Dne 23.9.2016 v 09:39 Martin Nowak via Digitalmars-d napsal(a):
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Bringing up this topic again b/c there was still almost
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Bringing up this topic again b/c there was still
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Bringing up this topic again b/c there was still almost no
feedback on the actual plan. Here is a summary.
- built-in
On Wednesday, 8 July 2015 at 06:11:25 UTC, Uranuz wrote:
My idea is slihtly of topic.
I thiking about some API for array and associative array
literals.
There is already an API for array literals, typesafe variadic
arguments.
void foo(int[] literal...);
foo([0, 1, 2, 3]);
But what do you
On Wednesday, 8 July 2015 at 08:24:00 UTC, Martin Nowak wrote:
On Wednesday, 8 July 2015 at 06:11:25 UTC, Uranuz wrote:
My idea is slihtly of topic.
I thiking about some API for array and associative array
literals.
There is already an API for array literals, typesafe variadic
arguments.
On 07/08/2015 02:20 PM, Uranuz wrote:
As far as I understand from that discussion it this feature was not
accepted because of template bloat. Am I wrong?
The main reason is that AA literals already have an incompatible semantic.
pragma(msg, typeof([0: ubyte(0), 1: ushort(1)]));
prints
On Saturday, 30 May 2015 at 08:22:21 UTC, Martin Nowak wrote:
On Saturday, 30 May 2015 at 00:50:39 UTC, Steven Schveighoffer
wrote:
I suggest first we build a library AA that sits beside real
AA, even if it doesn't . Then we create a test suite to prove
that the library AA can be a drop in
On 05/30/2015 10:50 AM, Vladimir Panteleev wrote:
Not sure how much this is a problem but implicit conversion from null
may also be an issue:
http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Not in my proposal, b/c it's an explicit conversion that does allocate a
translation wrapper.
On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote:
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a
bit more, I think there's only two cases
On Saturday, 30 May 2015 at 00:50:39 UTC, Steven Schveighoffer
wrote:
I suggest first we build a library AA that sits beside real AA,
even if it doesn't . Then we create a test suite to prove that
the library AA can be a drop in replacement. Then replace it :)
Writing the AA is NOT the
On Saturday, 30 May 2015 at 01:32:26 UTC, IgorStepanov wrote:
- attributes
We will able to deprecate attribute violations in transitional
version (with vtbl).
Yes, we'd have to deprecate attribute issues of the built-in AA
before we can switch.
Maybe that's already to disruptive.
-
On Saturday, 30 May 2015 at 08:50:21 UTC, Vladimir Panteleev
wrote:
http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Sorry, working link:
http://forum.dlang.org/post/asvcbsvfcxznwypttojk@192.168.0.1
On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote:
2. What issues disallows us to implement full library AA?
Except .stringof, .mangleof, and other compiler magic.
I see only two issues: opIndexCreate and building aa from
literals.
- error messages
- attributes
- literals (especially
On Saturday, 30 May 2015 at 08:51:31 UTC, Vladimir Panteleev
wrote:
On Saturday, 30 May 2015 at 08:50:21 UTC, Vladimir Panteleev
wrote:
http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Sorry, working link:
http://forum.dlang.org/post/asvcbsvfcxznwypttojk@192.168.0.1
We may say that
struct Foo
{
int a;
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
{
return Foo(val);
}
}
void test(Foo foo, int i)
{
assert(foo.a == i);
}
test(42, 42); -
test(Foo.opImplicitConstructFrom(42), 42);
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a bit
more, I think there's only two cases where we want implicit
construction: function argument lists
On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote:
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a
bit more, I think there's only two cases
On Friday, 29 May 2015 at 11:17:00 UTC, Martin Nowak wrote:
On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote:
Foo f;
f[5][3] = Foo(42); translates to
f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42);
auto x = f[5][4]; translates to
auto x =
On Friday, 29 May 2015 at 11:16:27 UTC, Mike wrote:
But, if you'll forgive my ignorance, what is the primary
motivation for migrating to a library AA?
- The current implementation uses runtime type information
(TypeInfo) to compute hashes and compare keys. That's at least 2
virtual
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
For my own reasons, a library AA is most welcome:
* separating library features from language features
* making features
On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote:
Foo f;
f[5][3] = Foo(42); translates to
f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42);
auto x = f[5][4]; translates to
auto x = f.opIndex!(false)(5).opIndex!(false)(3);
We shouldn't replace opIndexAssign though, b/c
On Friday, 29 May 2015 at 12:52:29 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote:
Sorry, I meant
f.opIndex!(true)(5).opIndexAssign(Foo(42), 3);
Added to the ER.
https://issues.dlang.org/show_bug.cgi?id=7753#c6
Thanks, but unfortunately, writing
On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote:
Sorry, I meant
f.opIndex!(true)(5).opIndexAssign(Foo(42), 3);
Added to the ER.
https://issues.dlang.org/show_bug.cgi?id=7753#c6
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
Thanks, but unfortunately, writing enhacement request to
bugzilla is equals to writing to /dev/null :)
No it's not, it keeps us from rediscussing the same stuff over
and over.
I'll create a DIP about this, when I'll have a free
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
What do you want about this syntax? Maybe you may suggest a
better solution?
The discussion drifts a little OT, if we have opIndexCreate, then
the library AA can be more compatible, but it still won't be a
drop-in replacement.
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessary
semantic changes, and provides an improved
On Friday, 29 May 2015 at 17:52:58 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
What do you want about this syntax? Maybe you may suggest a
better solution?
The discussion drifts a little OT, if we have opIndexCreate,
then the library AA can be more
On 5/29/15 4:41 PM, Martin Nowak wrote:
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessary semantic
On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates
On Monday, 25 May 2015 at 23:39:18 UTC, IgorStepanov wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
BTW, I have one idea. We may declare the AA ABI:
AA is a
On Wed, May 27, 2015 at 05:16:51PM +, IgorStepanov via Digitalmars-d wrote:
On Wednesday, 27 May 2015 at 14:12:02 UTC, Martin Nowak wrote:
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
Could you elaborate on what these magic semantics are?
and no easy solution exists
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
Could you elaborate on what these magic semantics are?
and no easy solution exists for the ++aa[key1][key2] case.
Is this specific to the pre-increment? aa[key1][key2]++ is
generally a useful pattern.
This applies to
On Wednesday, 27 May 2015 at 14:12:02 UTC, Martin Nowak wrote:
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev
wrote:
Could you elaborate on what these magic semantics are?
and no easy solution exists for the ++aa[key1][key2] case.
Is this specific to the pre-increment?
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
BTW, I have one idea. We may declare the AA ABI:
AA is a pointer to the next layout:
__vtbl
N bytes of data
and __vtbl
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Looks like a good step in the right direction.
Some
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Looks like a good step in the right direction.
Some questions about:
This provides a strong incentive to no longer use
42 matches
Mail list logo
