On 2012-11-14 08:46, Walter Bright wrote:
We agree that strings can be used globally as attributes with different
meanings, right?
Yes, but I would consider that a bad idea.
So why can't test.foo.bar also be used globally as an attribute with
different meanings? It's just a type name, it
Walter Bright, el 13 de November a las 16:49 me escribiste:
On 11/13/2012 2:55 PM, bearophile wrote:
Walter Bright:
consider the type int. Different modules impute different meanings into it
all the time, and it doesn't cause terrible compatibility problems between
modules.
The usage of
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella
wrote:
Can you provide one concrete case where it makes sense NOT to
restrict UDAs to
types and it's different from restricting exception to classes
derived from
Exception?
Thank you.
There was the example with Thrift...
On 2012-11-14 12:18, Tove wrote:
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella wrote:
Can you provide one concrete case where it makes sense NOT to restrict
UDAs to
types and it's different from restricting exception to classes derived
from
Exception?
Thank you.
There
On Wednesday, 14 November 2012 at 12:33:58 UTC, Jacob Carlborg
wrote:
I assume you mean something like:
struct UserProfile {
[1] i32 uid;
[2] string name;
[3] string blurb;
}
In that case I would much rather prefer this:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile
On Wednesday, 14 November 2012 at 13:03:18 UTC, David Nadlinger
wrote:
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
Tove, el 14 de November a las 13:55 me escribiste:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct
On 11/14/2012 03:31 PM, Leandro Lucarella wrote:
Tove, el 14 de November a las 13:55 me escribiste:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Now use
On Tuesday, 13 November 2012 at 01:08:01 UTC, Andrei Alexandrescu
wrote:
Update - we've crossed $20K! At this point we're one major
backer away from achieving the goal, and we're looking at a
number of options. Please share with your friends and
coworkers, and bring the discussion up with your
On Tuesday, 13 November 2012 at 01:08:01 UTC, Andrei Alexandrescu
wrote:
Update - we've crossed $20K! At this point we're one major
backer away from achieving the goal, and we're looking at a
number of options. Please share with your friends and
coworkers, and bring the discussion up with your
On 11/14/12 1:13 PM, Walter Bright wrote:
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the
fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct
On Monday, 22 October 2012 at 17:25:28 UTC, Andrei Alexandrescu
wrote:
We're on! For one month starting today, we're raising funding
for DConf 2013.
http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
Please pledge your support and encourage your
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote:
// in this nested scope, all uints are interpreted as belonging
to the thrift module.
[std.attributes(uint, thrift)]
struct UserProfile
...
// error detected at compile-time
[std.attributes(uint, thrift), std.attributes(uint,
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote:
// in this nested scope, all uints are interpreted as belonging
to the thrift module.
[std.attributes(uint, thrift)]
struct UserProfile
...
// error detected at compile-time
[std.attributes(uint, thrift), std.attributes(uint,
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote:
// in this nested scope, all uints are interpreted as belonging
to the thrift module.
[std.attributes(uint, thrift)]
struct UserProfile
...
// error detected at compile-time
[std.attributes(uint, thrift), std.attributes(uint,
On 11/14/2012 3:05 AM, Alex Rønne Petersen wrote:
On 14-11-2012 03:02, Andrei Alexandrescu wrote:
On 11/13/12 5:58 PM, Alex Rønne Petersen wrote:
On 14-11-2012 02:52, Andrei Alexandrescu wrote:
On 11/13/12 3:48 PM, Alex Rønne Petersen wrote:
Slices and delegates can't be loaded/stored
In your particular case, which this definitely is a bug and if only for
missing documentation that you should only use it from classes, you
might regardless be better of with writeln(f.prop.get) because you avoid
the needless copy with memory allocation/deallocation (if done
correctly) of the
On Tuesday, 13 November 2012 at 22:55:38 UTC, eskimo wrote:
Property is a struct and thus it is passed by value, which
means that
the signal is copied.
But wait! Due to alias get this;, f.prop shouldn't copy prop
but call get (which it does in the working - second - case)!
How to check?
On Wednesday, 14 November 2012 at 07:26:44 UTC, Tove wrote:
it would be a very useful feature to allow overload on void and
1 other type... as sometimes the return is very expensive to
calculate... I have seen this trick used by compiler build-in
functions.
struct A
{
int i;
string s;
On Wednesday, 14 November 2012 at 08:25:30 UTC, Rob T wrote:
Was the single conversion limitation specified by design, or do
we have room to expand it to allow for multiple conversions?
http://d.puremagic.com/issues/show_bug.cgi?id=6083
I guess it will be expanded to allow multiple
Am 13.11.2012 23:22, schrieb Walter Bright:
But I do see enormous value in shared in that it logically (and rather
forcefully) separates thread-local code from multi-thread code. For
example, see the post here about adding a destructor to a shared struct,
and having it fail to compile. The
Actually the (x) = y style delegates compute their return type exactly by
looking at the left-hand side. This exact thing is already being done. If
the ambiguity cannot be resolved, the return type is explicitly set OR the
result is casted to a type.
Having normal functions behave this way doesn't
On Wednesday, November 14, 2012 13:05:41 Gor Gyolchanyan wrote:
Actually the (x) = y style delegates compute their return type exactly by
looking at the left-hand side. This exact thing is already being done. If
the ambiguity cannot be resolved, the return type is explicitly set OR the
result
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and having
memory barriers would reduce race condition weirdness when locks aren't used
properly, so I think that it would be desirable to have memory barriers.
I'm not saying
On 11/13/2012 1:34 PM, Rob T wrote:
I'm wondering why overloading has been implemented to only match on the argument
list rather than the full signature which includes the return type? I know I
would use it if it was available.
I'm not requesting this to be a feature of D, I'm only asking why
On 11/14/2012 1:01 AM, Benjamin Thaut wrote:
I still don't agree with you there. The struct would have clearly outlived any
thread (as it was in the global scope) so at the point where it is destroyed
there should be really only one thread left. So it IS destroyed in a single
threaded context.
On 11/13/2012 11:37 PM, Jacob Carlborg wrote:
If the compiler should/does not add memory barriers, then is there a reason for
having it built into the language? Can a library solution be enough?
Memory barriers can certainly be added using library functions.
Am 14.11.2012 10:18, schrieb Walter Bright:
On 11/14/2012 1:01 AM, Benjamin Thaut wrote:
I still don't agree with you there. The struct would have clearly
outlived any
thread (as it was in the global scope) so at the point where it is
destroyed
there should be really only one thread left. So it
On 12/11/12 20:42, Jonathan M Davis wrote:
On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
I contend that the problem with built-in AA's is their implementation,
not the fact that they're built-in.
Oh, I agree, but we, as a group, have obviously failed to handle the
implementation of
But wait! Due to alias get this;, f.prop shouldn't copy prop
but call get (which it does in the working - second - case)!
- Also here the struct is copied, but the signal has no content yet and
thus no memory allocation yet occurred. (So no double free)
How to check? Remove the alias and
On 2012-11-14 10:20, Walter Bright wrote:
Memory barriers can certainly be added using library functions.
Is there then any real advantage of having it directly in the language?
--
/Jacob Carlborg
On 2012-11-14 08:56, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and having
memory barriers would reduce race condition weirdness when locks aren't used
properly, so I think that it would be desirable to have memory barriers. If
there's a major
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright
wrote:
[cut]
Guy makes the argument that users need to be able to extend the
vocabulary of a language and have those new words look like
built-in ones. We have that today, of course, with the ability
of defining new types. There is
On 13/11/2012 21:15, Iain Buclaw wrote:
But really, you got network on Raspi? Tarball up the binaries and scp
across the wire.
You know the RasPi is networked, I gave you login details for it
Its still building atm, do I do the tarballing after the make-install stage?
I'll read the scp
On Wednesday, November 14, 2012 10:49:41 renoX wrote:
That's not strictly true: type inference works better for
built-in types than for user-defined types, with auto x = 1; x
is an int, how do I have the same type of syntax for MyInt?
AFAIK I can't, that's why I have mixed feelings towards
On 11/14/2012 04:12 AM, Michel Fortin wrote:
On 2012-11-13 19:54:32 +, Timon Gehr timon.g...@gmx.ch said:
On 11/12/2012 02:48 AM, Michel Fortin wrote:
I feel like the concurrency aspect of D2 was rushed in the haste of
having it ready for TDPL. Shared, deadlock-prone synchronized
On 11/14/2012 1:31 AM, Jacob Carlborg wrote:
On 2012-11-14 10:20, Walter Bright wrote:
Memory barriers can certainly be added using library functions.
Is there then any real advantage of having it directly in the language?
Not that I can think of.
On 11/14/2012 1:23 AM, Benjamin Thaut wrote:
Could you please give an example where it would break?
Thread 1:
1. create shared object
2. pass reference to that object to Thread 2
3. destroy object
Thread 2:
1. manipulate that object
And whats the difference between:
struct Value
{
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in types than
for user-defined types, with auto x = 1; x is an int, how do I have the same
type of syntax for MyInt?
You can have user-defined literals in D:
auto x = MyInt(1);
Am 14.11.2012 11:42, schrieb Walter Bright:
On 11/14/2012 1:23 AM, Benjamin Thaut wrote:
Could you please give an example where it would break?
Thread 1:
1. create shared object
2. pass reference to that object to Thread 2
3. destroy object
Thread 2:
1. manipulate that object
On 14 November 2012 09:46, Alix Pexton alix.dot.pex...@gmail.dot.com wrote:
On 13/11/2012 21:15, Iain Buclaw wrote:
But really, you got network on Raspi? Tarball up the binaries and scp
across the wire.
You know the RasPi is networked, I gave you login details for it
Its still building
On Wednesday, November 14, 2012 11:49:22 Benjamin Thaut wrote:
Am 14.11.2012 11:42, schrieb Walter Bright:
On 11/14/2012 1:23 AM, Benjamin Thaut wrote:
Could you please give an example where it would break?
Thread 1:
1. create shared object
2. pass reference to that object to
On 11/14/2012 2:49 AM, Benjamin Thaut wrote:
Am 14.11.2012 11:42, schrieb Walter Bright:
On 11/14/2012 1:23 AM, Benjamin Thaut wrote:
Could you please give an example where it would break?
Thread 1:
1. create shared object
2. pass reference to that object to Thread 2
3. destroy
On 11/13/2012 3:18 AM, Sönke Ludwig wrote:
Am 13.11.2012 12:00, schrieb Walter Bright:
By operating on the expression, a lot more cases can be handled.
Yes, but _only_ doing that, the unique property is lost as soon as the
expression crosses the
statement border - then the type system somehow
Le 14/11/2012 10:31, Jacob Carlborg a écrit :
On 2012-11-14 10:20, Walter Bright wrote:
Memory barriers can certainly be added using library functions.
Is there then any real advantage of having it directly in the language?
The compiler can do more reordering in regard to barriers. For
On 11/14/2012 10:49 AM, renoX wrote:
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright wrote:
[cut]
Guy makes the argument that users need to be able to extend the
vocabulary of a language and have those new words look like built-in
ones. We have that today, of course, with the
On 2012-43-14 11:11, Walter Bright newshou...@digitalmars.com wrote:
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in
types than
for user-defined types, with auto x = 1; x is an int, how do I have
the same
type of syntax for MyInt?
On Wednesday, November 14, 2012 12:06:29 Simen Kjaeraas wrote:
On 2012-43-14 11:11, Walter Bright newshou...@digitalmars.com wrote:
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in
types than
for user-defined types, with auto x = 1; x
Am 14.11.2012 12:00, schrieb Walter Bright:
On 11/14/2012 2:49 AM, Benjamin Thaut wrote:
Am 14.11.2012 11:42, schrieb Walter Bright:
On 11/14/2012 1:23 AM, Benjamin Thaut wrote:
Could you please give an example where it would break?
Thread 1:
1. create shared object
2. pass reference
On 11/14/2012 01:53 AM, Walter Bright wrote:
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to one of our
current
On 11/14/2012 12:03 PM, Walter Bright wrote:
...
But how can it do recovery across a statement boundary?
Assign to a Unique!T variable, then use that Unique!T variable in the
next statement.
What he meant is how to create temporary pointers to the data and then
get an isolated reference
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright
wrote:
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language
successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases,
including valid double check locking (It has to be noted that
this idiom is used incorrectly in druntime ATM, which proves
both its usefullness and that it require
On 2012-11-14 10:30:46 +, Timon Gehr timon.g...@gmx.ch said:
On 11/14/2012 04:12 AM, Michel Fortin wrote:
On 2012-11-13 19:54:32 +, Timon Gehr timon.g...@gmx.ch said:
On 11/12/2012 02:48 AM, Michel Fortin wrote:
I feel like the concurrency aspect of D2 was rushed in the haste of
On 2012-11-14 11:38, Walter Bright wrote:
Not that I can think of.
Then we might want to remove it since it's either not working or
basically everyone has misunderstood how it should work.
--
/Jacob Carlborg
On 2012-11-14 12:04, deadalnix wrote:
The compiler can do more reordering in regard to barriers. For instance,
the compiler may reorder thread local read write accross the barrier.
This can't be done with a library solution.
I see.
--
/Jacob Carlborg
Le 14/11/2012 13:23, David Nadlinger a écrit :
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases, including
valid double check locking (It has to be noted that this idiom is used
incorrectly in druntime ATM, which proves
On Wednesday, 14 November 2012 at 06:32:19 UTC, Jonathan M Davis
wrote:
The one cast that I'd be a bit concerned about would be casting
the floating
point value in deepHash to its representative bytes. I believe
that the cast
itself is okay, but I don't think that it's necessarily the
case
On 14/11/2012 10:49, Iain Buclaw wrote:
You know how to cp, you know how to ssh? You should know how to scp. ;)
Assume I know nothing, its much safer, and probalbly quicker in the long
run ^^
A...
On 11/13/12 11:37 PM, Jacob Carlborg wrote:
On 2012-11-13 23:22, Walter Bright wrote:
But I do see enormous value in shared in that it logically (and rather
forcefully) separates thread-local code from multi-thread code. For
example, see the post here about adding a destructor to a shared
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and
having
memory barriers would reduce race condition weirdness when locks
aren't used
properly, so I think that it would be desirable to
On 11/14/12 1:20 AM, Walter Bright wrote:
On 11/13/2012 11:37 PM, Jacob Carlborg wrote:
If the compiler should/does not add memory barriers, then is there a
reason for
having it built into the language? Can a library solution be enough?
Memory barriers can certainly be added using library
On 11/14/12 1:31 AM, Jacob Carlborg wrote:
On 2012-11-14 10:20, Walter Bright wrote:
Memory barriers can certainly be added using library functions.
Is there then any real advantage of having it directly in the language?
It's not an advantage, it's a necessity.
Andrei
IIRC it was used prior to 2.030. In the spec, it is in the keyword list,
and it's also listed in the Migrating to shared article. That's all.
There are a small number of uses of it in the DMD test suite.
Is it still valid? Is it useful? Or has everyone forgotten that it still
exists?
On 11/14/2012 01:42 PM, Michel Fortin wrote:
On 2012-11-14 10:30:46 +, Timon Gehr timon.g...@gmx.ch said:
On 11/14/2012 04:12 AM, Michel Fortin wrote:
On 2012-11-13 19:54:32 +, Timon Gehr timon.g...@gmx.ch said:
On 11/12/2012 02:48 AM, Michel Fortin wrote:
I feel like the
On 11/14/12 4:23 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases, including
valid double check locking (It has to be noted that this idiom is used
incorrectly in druntime ATM, which proves
On Tue, 13 Nov 2012 22:52:42 -, Martin Drašar dra...@ics.muni.cz
wrote:
Dne 13.11.2012 17:44, Regan Heath napsal(a):
Does your dmd2\src\druntime\import\core\sys\windows\windows.d file have
a definition of WIN32_FILE_ATTRIBUTE_DATA on line 448?
Yup, it is there.
struct
On 11/14/12 4:47 AM, Jacob Carlborg wrote:
On 2012-11-14 11:38, Walter Bright wrote:
Not that I can think of.
Then we might want to remove it since it's either not working or
basically everyone has misunderstood how it should work.
Actually this hypothesis is false.
Andrei
On 14-11-2012 15:14, Andrei Alexandrescu wrote:
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and
having
memory barriers would reduce race condition weirdness when locks
aren't used
Can we get this updated? std.traits.ParameterIdentifierTuple and
std.traits.ParameterDefaultValueTuple are not showing up, but have been
around at least since 2.060 was released
Le 14/11/2012 15:39, Alex Rønne Petersen a écrit :
On 14-11-2012 15:14, Andrei Alexandrescu wrote:
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and
having
memory barriers would
On 11/14/12 6:39 AM, Alex Rønne Petersen wrote:
On 14-11-2012 15:14, Andrei Alexandrescu wrote:
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable, and
having
memory barriers would reduce
On 2012-11-14 15:33, Andrei Alexandrescu wrote:
Actually this hypothesis is false.
That we should remove it or that it's not working/nobody understands
what it should do? If it's the latter then this thread is the evidence
that my hypothesis is true.
--
/Jacob Carlborg
On 14-11-2012 15:32, Andrei Alexandrescu wrote:
On 11/14/12 4:23 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases, including
valid double check locking (It has to be noted that this idiom is
On 14-11-2012 15:50, deadalnix wrote:
Le 14/11/2012 15:39, Alex Rønne Petersen a écrit :
On 14-11-2012 15:14, Andrei Alexandrescu wrote:
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be valuable,
I'd like to download a e-reader file on my Android tablet. But
the .mobi file seems to be missing...
On http://dlang.org/download.html, in the Documentation
Downloads section, there's a link called D Programming Language
Specification 2.0 ebook. Following the link
On 2012-11-14 15:22, Andrei Alexandrescu wrote:
It's not an advantage, it's a necessity.
Walter seems to indicate that there is no technical reason for shared
to be part of the language. I don't know how these memory barriers work,
that's why I'm asking. Does it need to be in the language
On Wed, Nov 14, 2012 at 12:51:45AM +0100, deadalnix wrote:
Le 13/11/2012 20:13, Jonathan M Davis a écrit :
On Tuesday, November 13, 2012 09:45:17 H. S. Teoh wrote:
Unfortunately, using ranges in their most general sense is looking
like a pipe dream to me right now, and I'm ready to just move
Current Github diff is very primitive and is almost like unified diff
format which isn't for humans at all. This complicates and slows down
code revision simultaneously reducing its quality.
Something must be done about it to stop wasting people time without any
real reason.
Possible
On 14-11-2012 16:08, Andrei Alexandrescu wrote:
On 11/14/12 6:39 AM, Alex Rønne Petersen wrote:
On 14-11-2012 15:14, Andrei Alexandrescu wrote:
On 11/14/12 1:19 AM, Walter Bright wrote:
On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
Being able to have double-checked locking work would be
On Wed, Nov 14, 2012 at 10:25:53AM +0100, Don Clugston wrote:
On 12/11/12 20:42, Jonathan M Davis wrote:
On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
I contend that the problem with built-in AA's is their
implementation, not the fact that they're built-in.
Oh, I agree, but we, as
On 14.11.2012 15:28, Regan Heath wrote:
Well.. druntime is built into a lib, and phobos is built using that
lib. So, the only way I can imagine reproducing this error is by
altering dmd2\src\druntime\import\core\sys\windows\windows.d, rebuilding
druntime, then rebuilding phobos and replacing
On Wed, 14 Nov 2012 19:27:46 +0400
Denis Shelomovskij verylonglogin@gmail.com wrote:
Current Github diff is very primitive and is almost like unified diff
format which isn't for humans at all.
I'm pretty sure it basically *is* unified diff format, just with the
line-starting +/- chars
On Wednesday, 14 November 2012 at 15:19:12 UTC, Justin C
Calvarese wrote:
I'd like to download a e-reader file on my Android tablet. But
the .mobi file seems to be missing...
[snip]
I'm appreciate some help since I get the impression it's not
particular easy to generate the ebook on my own.
On Wednesday, 14 November 2012 at 14:32:34 UTC, Andrei
Alexandrescu wrote:
On 11/14/12 4:23 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix
wrote:
That is what java's volatile do. It have several uses cases,
including
valid double check locking (It has to
There are people who actually like it the way it is.
And you still can clone the GitHub repository to a local machine,
and use your favorite toolset.
On Wednesday, 14 November 2012 at 14:16:57 UTC, Andrei
Alexandrescu wrote:
On 11/14/12 1:20 AM, Walter Bright wrote:
On 11/13/2012 11:37 PM, Jacob Carlborg wrote:
If the compiler should/does not add memory barriers, then is
there a
reason for
having it built into the language? Can a library
On Wed, 14 Nov 2012 15:37:19 -, Martin Drasar dra...@ics.muni.cz
wrote:
On 14.11.2012 15:28, Regan Heath wrote:
Well.. druntime is built into a lib, and phobos is built using that
lib. So, the only way I can imagine reproducing this error is by
altering
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright
wrote:
I'm not requesting this to be a feature of D, I'm only asking
why it is not
being done.
Because types are resolved bottom-up, and if the return type
were part of the overloading, there would be no sensible rule
to
On Wednesday, 14 November 2012 at 15:08:35 UTC, Andrei
Alexandrescu wrote:
Sorry, I was imprecise. We need to (a) define intrinsics for
loading and storing data with high-level semantics (a short
list: acquire, release, acquire+release, and
sequentially-consistent) and THEN (b) implement the
On Wednesday, 14 November 2012 at 13:19:12 UTC, deadalnix wrote:
The main drawback with that solution is that the compiler can't
optimize thread local read/write regardless of shared
read/write. This is wasted opportunity.
You mean moving non-atomic loads/stores across atomic
instructions?
On 11/14/12 7:11 AM, Alex Rønne Petersen wrote:
On 14-11-2012 15:32, Andrei Alexandrescu wrote:
On 11/14/12 4:23 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases, including
valid double
On 11/14/12 7:14 AM, Jacob Carlborg wrote:
On 2012-11-14 15:33, Andrei Alexandrescu wrote:
Actually this hypothesis is false.
That we should remove it or that it's not working/nobody understands
what it should do? If it's the latter then this thread is the evidence
that my hypothesis is
On 11/14/12 7:16 AM, Jacob Carlborg wrote:
On 2012-11-14 15:22, Andrei Alexandrescu wrote:
It's not an advantage, it's a necessity.
Walter seems to indicate that there is no technical reason for shared
to be part of the language.
Walter is a self-confessed dilettante in threading. To be
On Wednesday, 14 November 2012 at 15:27:36 UTC, Denis
Shelomovskij wrote:
* Instruct reviewers to install SmartGit, KDiff3 or something
with human readable diff and fetch from repos of pull request
senders.
- Will spend reviewers time.
- Will not auto-update on pull update.
I doubt
On 11/14/12 7:29 AM, H. S. Teoh wrote:
But since this isn't going to be fixed properly, then the only solution
left is to arbitrarily declare transient ranges as not ranges (even
though the concept of ranges itself has no such implication, and many
algorithms don't even need such assumptions),
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
I'm wondering why overloading has been implemented to only
match on the argument list rather than the full signature which
includes the return type? I know I would use it if it was
available.
I'm not requesting this to be a feature
On 11/14/12 1:25 AM, Don Clugston wrote:
On 12/11/12 20:42, Jonathan M Davis wrote:
On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
I contend that the problem with built-in AA's is their implementation,
not the fact that they're built-in.
Oh, I agree, but we, as a group, have
1 - 100 of 249 matches
Mail list logo
