On 2012-11-14 22:13, Walter Bright wrote:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Just because it is not a builtin type does not change anything.
Sure you _can_ but it would be quite stupid. With user defined types
there is at least some
On 2012-11-14 23:39, Andrei Alexandrescu wrote:
I think a simple way to put this is that attribute name lookup works the
same as ordinary symbol lookup. Assuming we did a good job at the
latter, the former doesn't introduce any specific issues.
Exactly.
--
/Jacob Carlborg
On Wednesday, 14 November 2012 at 23:57:38 UTC, David Nadlinger
wrote:
Also, your solution is more complex than simply using types,
yet less flexible: What if you want to use uint attributes
from two libraries on the same type?
David
I disagree, you can always fallback to using user defined
Timon Gehr, el 14 de November a las 17:25 me escribiste:
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
..and the round goes on with a new bunch of fundamental fixes and
improvements :)
http://mono-d.alexanderbothe.com
Issues go here https://github.com/aBothe/Mono-D/issues as usual,
and the direct download for all Mac/Windows users that have
MonoDevelop 3.0.4.7:
Am Thu, 15 Nov 2012 19:46:15 +0100
schrieb alex i...@alexanderbothe.com:
..and the round goes on with a new bunch of fundamental fixes and
improvements :)
http://mono-d.alexanderbothe.com
Issues go here https://github.com/aBothe/Mono-D/issues as usual,
and the direct download for all
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your proposal, if you want to use
two libraries together which are expecting
(Sorry for the duplicated post, I have realized it's better to
show this here than D.learn)
Notes about some ways to write code and avoid some mistakes.
http://www.reddit.com/r/programming/comments/138j4t/static_typing_contracts_unit_tests_and_more/
Bye,
bearophile
On 11/15/12, Vladimir Panteleev vladi...@thecybershadow.net wrote:
I'd love to look into writing a wiki syntax converter to move all
the content from ProWiki to a new MediaWiki instance
Well even if we don't have that we will have an opportunity to review
and update outdated articles.
On Thursday, 15 November 2012 at 02:51:08 UTC, Ellery Newcomer
wrote:
Just tried building a shared library on linux with dmd (and
calling it from C).
It works! Holy crap, it even runs my static constructors and
unittests! I only had to screw with the linking process a
little bit!
It
On Thursday, 15 November 2012 at 08:28:09 UTC, Andrej Mitrovic
wrote:
On 11/15/12, Vladimir Panteleev vladi...@thecybershadow.net
wrote:
I'd love to look into writing a wiki syntax converter to move
all
the content from ProWiki to a new MediaWiki instance
Well even if we don't have that we
On Wednesday, 14 November 2012 at 09:31:47 UTC, eskimo wrote:
But first it is copied to every generic function that might be
called on
the way.
Ok, I guess it just doesn't do what I understood it to do (which
is too bad, but to be expected with a new language). In any case
you would appear
On 14 November 2012 19:54, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 11/14/12 9:31 AM, David Nadlinger wrote:
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
On 15 November 2012 04:30, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 11/11/12 6:30 PM, Walter Bright wrote:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
This is very
On 2012-11-14 22:06, Walter Bright wrote:
I hate to repeat myself, but:
Thread 1:
1. create shared object
2. pass reference to that object to Thread 2
3. destroy object
Thread 2:
1. manipulate that object
Why would the object be destroyed if there's still a reference to
On Thu, 2012-11-15 at 09:53 +0100, Joe wrote:
On Wednesday, 14 November 2012 at 09:31:47 UTC, eskimo wrote:
But first it is copied to every generic function that might be
called on
the way.
Ok, I guess it just doesn't do what I understood it to do (which
is too bad, but to be expected
On 2012-11-15 08:51, Thomas Koch wrote:
You're right about make. However the Makefiles that one needs today for
Debian packages are so trivial that it's not worth to worry about it. The
most basic debian/rules (which is a Makefile) looks like:
#!/usr/bin/make -f
On 11/14/2012 11:24 PM, Walter Bright wrote:
On 11/14/2012 3:18 AM, Timon Gehr wrote:
template Foo(alias a){ }
struct S{}
alias S X; // ok
alias int Y; // ok
mixin Foo!S; // ok
mixin Foo!int; // not ok
Please fix that. (Everything should be ok.)
Please file a bugzilla for that.
On 2012-11-15 10:22, Manu wrote:
Not to repeat my prev post... but in reply to Walter's take on it, it
would be interesting if 'shared' just added implicit lock()/unlock()
methods to do the mutex acquisition and then remove the cast
requirement, but have the language runtime assert that the
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't need to
write:
auto x = int(1);
suppose I want a size_t?
On 14/11/12 23:16, Walter Bright wrote:
On 11/14/2012 12:06 PM, Sean Kelly wrote:
On Nov 14, 2012, at 6:26 AM, Don Clugston d...@nospam.com wrote:
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.
On 2012-11-15 11:28, Don Clugston wrote:
However, there is one case in the test suite which is unclear to me:
extern(C) __thread int x;
Is there any other way to do this?
extern (C) int x;
extern(C) doesn't make it global.
--
/Jacob Carlborg
On 15 November 2012 12:14, Jacob Carlborg d...@me.com wrote:
On 2012-11-15 10:22, Manu wrote:
Not to repeat my prev post... but in reply to Walter's take on it, it
would be interesting if 'shared' just added implicit lock()/unlock()
methods to do the mutex acquisition and then remove the
On 11/15/2012 2:24 AM, Joseph Rushton Wakeling wrote:
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't need to
write:
auto x = int(1);
suppose I want a size_t?
size_t x = 1;
On 11/15/2012 2:28 AM, Don Clugston wrote:
However, there is one case in the test suite which is unclear to me:
extern(C) __thread int x;
Is there any other way to do this?
extern(C) int x;
Hey guys!
I just wanted to say that D is really really really awesome and I wanted
to thank everyone contributing to it.
I think what D needs the most at the moment is bug fixing so I am very
pleased to read the commit messages:
Fixed bug ...
Fixed bug ...
Fixed bug ...
Fixed bug ...
.
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:k81k6s$1qm7$1...@digitalmars.com...
On 11/14/12 5:30 PM, Daniel Murphy wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:k80l8p$397$1...@digitalmars.com...
On 11/14/12 7:29 AM, H. S. Teoh
On Thu, 15 Nov 2012 04:33:20 -, Michel Fortin
michel.for...@michelf.ca wrote:
On 2012-11-15 02:51:13 +, Jonathan M Davis jmdavisp...@gmx.com
said:
I have no idea what we want to do about this situation though.
Regardless of
what we do with memory barriers and the like, it has no
On Thursday, November 15, 2012 22:07:22 Daniel Murphy wrote:
Is that really good enough? Keeping ranges simple is important, but so is
making the obvious solution 'just work'.
std.array.array will never work with ranges with a transient front unless it
somehow knew when it was and wasn't
On Wednesday, November 14, 2012 20:32:35 Andrei Alexandrescu wrote:
TDPL 13.14 explains that inside synchronized classes, top-level shared
is automatically lifted.
Then it's doing the casting for you. I suppose that that's an argument that
using synchronized classes when dealing with shared is
On Thursday, November 15, 2012 11:22:30 Manu wrote:
Not to repeat my prev post... but in reply to Walter's take on it, it would
be interesting if 'shared' just added implicit lock()/unlock() methods to
do the mutex acquisition and then remove the cast requirement, but have the
language runtime
On Thursday, November 15, 2012 10:22:22 Jacob Carlborg wrote:
On 2012-11-14 22:06, Walter Bright wrote:
I hate to repeat myself, but:
Thread 1:
1. create shared object
2. pass reference to that object to Thread 2
3. destroy object
Thread 2:
1. manipulate
Am 15.11.2012 12:48, schrieb Jonathan M Davis:
Yeah. If the reference passed across were shared, then the runtime should see
it as having multiple references, and if it's _not_ shared, that means that
you cast shared away (unsafe, since it's a cast) and passed it across threads
without making
std.array.array will never work with ranges with a transient
front unless it
somehow knew when it was and wasn't appropriate to dup, which
it's not going
to know purely by looking at the type of front. The creator of
the range would
have to tell them somehow. And even then, it wouldn't work
Le 14/11/2012 21:01, Sean Kelly a écrit :
On Nov 14, 2012, at 6:32 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org
wrote:
This is a simplification of what should be going on. The
core.atomic.{atomicLoad, atomicStore} functions must be intrinsics so the
compiler generate sequentially
On Thursday, November 15, 2012 13:17:12 jerro wrote:
std.array.array will never work with ranges with a transient
front unless it
somehow knew when it was and wasn't appropriate to dup, which
it's not going
to know purely by looking at the type of front. The creator of
the range would
On 15.11.2012 11:52, Manu wrote:
On 15 November 2012 12:14, Jacob Carlborg d...@me.com
mailto:d...@me.com wrote:
On 2012-11-15 10:22, Manu wrote:
Not to repeat my prev post... but in reply to Walter's take on
it, it
would be interesting if 'shared' just added
On Thursday, November 15, 2012 14:32:47 Manu wrote:
On 15 November 2012 13:38, Jonathan M Davis jmdavisp...@gmx.com wrote:
I don't really see the difference, other than, as you say, the cast is
explicit.
Obviously the possibility for the situation you describe exists, it's
equally possible
On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:
array(map!a.dup(stdin.byLine()))
As it seems there is a good way of handling ranges with transient front
for algorithms that need a persistent front?
Why not simply document any transient range to be transient (should be
anyway) and
Le 14/11/2012 23:21, Andrei Alexandrescu a écrit :
On 11/14/12 12:00 PM, Sean Kelly wrote:
On Nov 14, 2012, at 6:16 AM, Andrei
Alexandrescuseewebsiteforem...@erdani.org 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
Le 14/11/2012 22:09, Walter Bright a écrit :
On 11/14/2012 7:08 AM, 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
Le 15/11/2012 10:08, Manu a écrit :
The Nintendo Wii for instance, not an unpopular machine, only sold 130
million units! Does not have synchronisation instructions in the
architecture (insane, I know, but there it is. I've had to spend time
working around this in the past).
I'm sure it's not
Am 15.11.2012 05:32, schrieb Andrei Alexandrescu:
On 11/14/12 7:24 PM, Jonathan M Davis wrote:
On Thursday, November 15, 2012 03:51:13 Jonathan M Davis wrote:
I have no idea what we want to do about this situation though. Regardless of
what we do with memory barriers and the like, it has no
On Thursday, 15 November 2012 at 12:57:24 UTC, Jonathan M Davis
wrote:
It's looking like this comes down to either banning ranges with
transient
fronts entirely (and changing how ByLine and ByChunk work), or
we're going to
have to deal with quirks like array(map!a.dup(file.byLine()))
not
On Thursday, 15 November 2012 at 11:07:05 UTC, eskimo wrote:
Hey guys!
I just wanted to say that D is really really really awesome and
I wanted
to thank everyone contributing to it.
I think what D needs the most at the moment is bug fixing so I
am very
pleased to read the commit messages:
On Thursday, 15 November 2012 at 09:37:55 UTC, eskimo wrote:
But, considering that the alias this triggers only when you are
issuing
an operation not supported by the struct itself, it is pretty
reasonable
behaviour and everything else would be pretty surprising.
Best regards,
Robert
I
On 15 November 2012 15:00, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Thursday, November 15, 2012 14:32:47 Manu wrote:
On 15 November 2012 13:38, Jonathan M Davis jmdavisp...@gmx.com wrote:
I don't really see the difference, other than, as you say, the cast is
explicit.
Obviously
On 10/22/2012 07:25 PM, Andrei Alexandrescu wrote:
Please pledge your support and encourage your friends to do the same. Hope to
see you in 2013!
About that t-shirt thing -- is Kickstarter really accurate to say US only? Or
can you enter an EU address and pay shipping charges?
On 15/11/12 11:54, Walter Bright wrote:
On 11/15/2012 2:28 AM, Don Clugston wrote:
However, there is one case in the test suite which is unclear to me:
extern(C) __thread int x;
Is there any other way to do this?
extern(C) int x;
What about extern(C) variables which are not thread local?
On 15-11-2012 08:35, Thomas Koch wrote:
Andrei Alexandrescu wrote:
On 11/14/12 12:36 PM, Andrej Mitrovic wrote:
On 11/14/12, Alex Rønne Petersena...@lycus.org wrote:
Or we could switch to Phabricator for our entire review process which
has an absolutely awesome side-by-side diff and is
On 15-11-2012 15:42, Don Clugston wrote:
On 15/11/12 11:54, Walter Bright wrote:
On 11/15/2012 2:28 AM, Don Clugston wrote:
However, there is one case in the test suite which is unclear to me:
extern(C) __thread int x;
Is there any other way to do this?
extern(C) int x;
What about
:-) Indeed, that is the only thing that surprised me too (but not as
much as in another language, because of D's capabilities). The solution
I think is this overload found in std.format of formatValue:
void formatValue(Writer, T, Char)(Writer w, auto ref T val, ref
FormatSpec!Char f)
if ((is(T ==
On 11/15/12 6:39 AM, Joseph Rushton Wakeling wrote:
On 10/22/2012 07:25 PM, Andrei Alexandrescu wrote:
Please pledge your support and encourage your friends to do the same.
Hope to
see you in 2013!
About that t-shirt thing -- is Kickstarter really accurate to say US
only? Or can you enter an
On 11/15/12 1:08 AM, Manu wrote:
On 14 November 2012 19:54, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
Yah, the whole point here is that we need something IN THE LANGUAGE
DEFINITION about atomicLoad and atomicStore. NOT IN THE
After working a bit more on it (accompanied by a bad flu with 40 °C fever, so
hopefully it's not all
wrong in reality), I got a library approach that allows to use shared objects
in a (statically
checked) safe and comfortable way. As a bonus, it also introduces an
isolated/unique type that can
11/15/2012 1:06 AM, Walter Bright пишет:
On 11/14/2012 3:14 AM, Benjamin Thaut wrote:
A small code example which would break as soon as we allow destructing
of shared
value types would really be nice.
I hate to repeat myself, but:
Thread 1:
1. create shared object
2. pass reference
Would it be useful if 'shared' in D did something like 'volatile'
in C++ (as in, Andrei's article on volatile-correctness)?
http://www.drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766
11/15/2012 8:33 AM, Michel Fortin пишет:
If you want to declare the mutex separately, you could do it by
specifying a variable instead of a type in the variable declaration:
Mutex m;
synchronized(m) int i;
synchronized(i)
{
// implicit: m.lock();
//
On Wednesday, 14 November 2012 at 19:12:59 UTC, Timon Gehr wrote:
On 11/14/2012 06:43 PM, foobar wrote:
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
On Nov 15, 2012, at 3:16 AM, Regan Heath re...@netmail.co.nz wrote:
I suggested something similar as did Sönke:
http://forum.dlang.org/thread/k7orpj$1tt5$1...@digitalmars.com?page=2#post-op.wnnuiio554xghj:40puck.auriga.bhead.co.uk
According to deadalnix the compiler magic I suggested to add
11/15/2012 5:20 PM, monarch_dodra пишет:
On Thursday, 15 November 2012 at 12:57:24 UTC, Jonathan M Davis wrote:
It's looking like this comes down to either banning ranges with transient
fronts entirely (and changing how ByLine and ByChunk work), or we're
going to
have to deal with quirks like
On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
[…]
[2] wiki.debian.org/UpstreamGuide
I've read that page and from my understanding they prefer to use make:
Please don't use SCons
Using waf as build system is discouraged
Comments made by people who are steeped in
On Nov 14, 2012, at 6:28 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 11/14/12 4:50 PM, Sean Kelly wrote:
On Nov 14, 2012, at 2:25 PM, Andrei
Alexandrescuseewebsiteforem...@erdani.org wrote:
On 11/14/12 1:09 PM, Walter Bright wrote:
Yes. And also, I agree that having
On Nov 11, 2012, at 6:30 PM, Walter Bright newshou...@digitalmars.com wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
So what
On Nov 15, 2012, at 4:54 AM, deadalnix deadal...@gmail.com wrote:
Le 14/11/2012 21:01, Sean Kelly a écrit :
On Nov 14, 2012, at 6:32 AM, Andrei
Alexandrescuseewebsiteforem...@erdani.org wrote:
This is a simplification of what should be going on. The
core.atomic.{atomicLoad, atomicStore}
On Nov 15, 2012, at 5:10 AM, deadalnix deadal...@gmail.com wrote:
Le 14/11/2012 23:21, Andrei Alexandrescu a écrit :
On 11/14/12 12:00 PM, Sean Kelly wrote:
On Nov 14, 2012, at 6:16 AM, Andrei
Alexandrescuseewebsiteforem...@erdani.org wrote:
On 11/14/12 1:20 AM, Walter Bright wrote:
On
On Nov 15, 2012, at 5:16 AM, deadalnix deadal...@gmail.com wrote:
What is the point of ensuring that the compiler does not reorder load/stores
if the CPU is allowed to do so ?
Because we can write ASM to tell the CPU not to. We don't have any such
ability for the compiler right now.
On Nov 15, 2012, at 7:17 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 11/15/12 1:08 AM, Manu wrote:
Side note: I still think a convenient and fairly practical solution is
to make 'shared' things 'lockable'; where you can lock()/unlock() them,
and assignment to/from
Russel Winder wrote:
On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
[…]
[2] wiki.debian.org/UpstreamGuide
I've read that page and from my understanding they prefer to use make:
Please don't use SCons
Using waf as build system is discouraged
Comments made by people who are
Since the Something needs to happen with shared thread is currently split up
into a low level
discussion (atomic operations, memory barriers etc.) and a high level one
(classes, mutexes), it
probably makes sense to explicitly state that this proposal here applies more
to the latter.
On 15 November 2012 15:13, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 11/15/12 6:39 AM, Joseph Rushton Wakeling wrote:
On 10/22/2012 07:25 PM, Andrei Alexandrescu wrote:
Please pledge your support and encourage your friends to do the same.
Hope to
see you in 2013!
About
I've been wondering for a couple of years about why overloading
stops at the argument sig in almost all languages, but so far I
have not seen a good reason why this must be so.
From what I've read so far, the reason why full overloading is
not being done, is because it is not being done.
On Thursday, 15 November 2012 at 17:18:04 UTC, Rob T wrote:
I've been wondering for a couple of years about why overloading
stops at the argument sig ...
[SNIP]
--rt
I'd say because overall, you gain *very* little out of it, and it
costs you much more complex compiler rules.
Most of all
On Thursday, 15 November 2012 at 11:07:05 UTC, eskimo wrote:
Hey guys!
I just wanted to say that D is really really really awesome and
I wanted
to thank everyone contributing to it.
I think what D needs the most at the moment is bug fixing so I
am very
pleased to read the commit messages:
monarch_dodra:
I mean, are there even any real use-cases for overload on
return type?
In Haskell many functions are overloaded on the return type
(like the fromString function), and it's nice. But Haskell is
able to do it because it has a global type inferencer.
Bye,
bearophile
Am 14.11.2012 20:07, schrieb Timon Gehr:
On 11/14/2012 06:30 PM, Rob T wrote:
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
On 11/15/2012 8:17 AM, Martin Drašar wrote:
Dne 15.11.2012 7:45, Rainer Schuetze napsal(a):
[...]
importcore.sys.windows.windows(C:\Program
Files\D\dmd2\windows\bin\..\..\src\druntime\import\core\sys\windows\windows.di)
since dmd 2.060 most of the files in druntme/import are
On Thu, Nov 15, 2012 at 04:38:04AM -0800, Jonathan M Davis wrote:
On Thursday, November 15, 2012 13:17:12 jerro wrote:
std.array.array will never work with ranges with a transient front
unless it somehow knew when it was and wasn't appropriate to dup,
which it's not going to know purely
Most of the slides of the recent 2012 LLVM Developers' Meeting
are not yet available. But there are the slides of the Parsing
Documentation Comments in Clang talk by Dmitri Gribenko:
http://llvm.org/devmtg/2012-11/Gribenko_CommentParsing.pdf
With this feature added to Clang (you need the
On Thursday, 15 November 2012 at 17:33:24 UTC, monarch_dodra
wrote:
I'd say because overall, you gain *very* little out of it, and
it costs you much more complex compiler rules.
But how little, and for how much extra cost? Overloading already
has a cost to it, and it's really difficult for
On Thu, Nov 15, 2012 at 02:14:15PM +0100, eskimo wrote:
On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:
array(map!a.dup(stdin.byLine()))
As it seems there is a good way of handling ranges with transient
front for algorithms that need a persistent front?
Why not simply
On 11/15/12, bearophile bearophileh...@lycos.com wrote:
Currently in D if you have a documentation comment like this it
generates no warnings or notes
So you open dlang.org, hit the edit button, and fix it. Doing
semantics in comments is beyond overkill.
And soon enough we won't have to use
It would be really awesome if you could ship the shirts to the
EU. I pledged 50$ nonetheless, if only there'll be recordings it
will be awesome enough :)
On Thursday, 15 November 2012 at 15:13:28 UTC, Andrei
Alexandrescu wrote:
On 11/15/12 6:39 AM, Joseph Rushton Wakeling wrote:
On
On 2012-11-15 11:52, Manu wrote:
Interesting concept. Nice idea, could certainly be useful, but it
doesn't address the problem as directly as my suggestion.
There are still many problem situations, for instance, any time a
template is involved. The template doesn't know to do that internally,
On Wednesday, 14 November 2012 at 22:23:17 UTC, Walter Bright
wrote:
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't
need to write:
auto x = int(1);
If you're going to argue that D should have some facility to
create user-defined
On 11/15/2012 6:46 AM, Alex Rønne Petersen wrote:
I think most people are aware of this 'quirk' from what I've seen in binding
projects, so it's probably not a big deal.
Also, remember that C code can now have thread local globals, too. Both are
expressible in D, it's just that the default
On 11/15/2012 6:42 AM, Don Clugston wrote:
On 15/11/12 11:54, Walter Bright wrote:
On 11/15/2012 2:28 AM, Don Clugston wrote:
However, there is one case in the test suite which is unclear to me:
extern(C) __thread int x;
Is there any other way to do this?
extern(C) int x;
What about
On 2012-11-15 17:23, Russel Winder wrote:
Comments made by people who are steeped in Autoconf/Automake and haven't
actually used more modern systems such as SCons or Waf.
The comments on the website are almost, but not quite, totally wrong on
all important points.
I'm not saying that they're
[[I suspect this is getting way off-topic for this list, so if
instructed to take it elsewhere will be happy to do so as long as
elsewhere is defined.]]
On Thu, 2012-11-15 at 17:52 +0100, Thomas Koch wrote:
[…]
The website is a wiki site edited by many people over a longer time
period. If you
On Thu, 2012-11-15 at 20:42 +0100, Jacob Carlborg wrote:
[…]
I'm not saying that they're right or wrong. I'm saying that they're
there and it's obviously someones opinion. It also indicates that
something that doesn't use Makefiles is not accepted or harder to get
accepted.
I just
On 2012-11-15 20:32, Era Scarecrow wrote:
Hmmm... Correct me if I'm wrong, but you can create/use opAssign,
correct? Although that doesn't work during initialization...
struct MyInt
{
int i;
ref MyInt opAssign(int rhs) {
i = rhs;
return this;
}
}
MyInt x = MyInt(10);
Am Thu, 15 Nov 2012 20:15:15 +0100
schrieb Andrej Mitrovic andrej.mitrov...@gmail.com:
Doing semantics in comments is beyond overkill.
They are DDoc and attached to a symbol. I've seen IDEs give
information on errors in documentation comments on the fly.
If at some point we can also
On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
Am 14.11.2012 20:07, schrieb Timon Gehr:
On 11/14/2012 06:30 PM, Rob T wrote:
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
On 11/15/2012 11:54 AM, Walter Bright wrote:
size_t x = 1;
Complete misunderstanding there -- I'd interpreted Simen's remark as saying that
e.g. auto x = 1; would automatically assign the correct type where builtins were
concerned, and I was pointing out that this wouldn't cover all
On 11/14/2012 08:32 PM, Jonathan M Davis wrote:
On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:
That is a very imprecise approximation. I think it does not cover any
ground: The day eg. 'array' will require this kind of non-transient
element range is the day where I will write my
On 11/14/2012 11:18 PM, Andrei Alexandrescu wrote:
On 11/14/12 11:18 AM, Timon Gehr wrote:
On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:
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
When I post on these forums to ask for new features (e.g.
iterators), you say that you won't be adding any new features at
the moment, and that you are instead concentrating on making the
language stable and usable.
However, when I post on these forums to ask for bugs to be fixed
(e.g. the
On Wednesday, 14 November 2012 at 17:54:16 UTC, Andrei
Alexandrescu wrote:
That is correct. My point is that compiler implementers would
follow some specification. That specification would contain
informationt hat atomicLoad and atomicStore must have special
properties that put them apart from
On Thursday, 15 November 2012 at 16:43:14 UTC, Sean Kelly wrote:
On Nov 15, 2012, at 5:16 AM, deadalnix deadal...@gmail.com
wrote:
What is the point of ensuring that the compiler does not
reorder load/stores if the CPU is allowed to do so ?
Because we can write ASM to tell the CPU not to.
On Thursday, 15 November 2012 at 20:58:55 UTC, Marco Leise wrote:
Am Thu, 15 Nov 2012 20:15:15 +0100
schrieb Andrej Mitrovic andrej.mitrov...@gmail.com:
Doing semantics in comments is beyond overkill.
They are DDoc and attached to a symbol. I've seen IDEs give
information on errors in
1 - 100 of 209 matches
Mail list logo
