On Monday, 25 March 2013 at 13:02:49 UTC, bearophile wrote:
foobar:
"idiomatic" is a relative term, tightly coupled to a specific
language. Idiomatic D code for example is very different from
idiomatic Haskell code.
Idiomatic Python style in D would be very unidiomatic D code
and
On Saturday, 23 March 2013 at 15:59:12 UTC, Jacob Carlborg wrote:
On 2013-03-23 16:55, John Colvin wrote:
A simple example is matplotlib.pyplot.plot
There are so many possible flags and parameters that can be
passed in
order to get the exact behaviour you want, but commonly you'll
only want
On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
foobar:
Code that needs named parameters to be more readable is poorly
designed code in the first place.
Have you used a language where the usage of named arguments is
idiomatic, like Python, Scala or Ada? They are sometimes
On Friday, 22 March 2013 at 21:41:46 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
WTF? What do kwargs have to do with programming? Sounds
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
WTF? What do kwargs have to do with programming? Sounds more
like a half-Klingon & half-Ferengi species to me.
kwargs = keyword arguments
It's a common naming conv
On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
With credit for inspiration to David Medlock in this post--
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com
...
// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)
/
ssing all major
decisions in this
group and we're switching full-bore to DIPs.
The "alias this" syntax the foobar mentioned was removed under
the radar
and only discussed in a pull request.
I agree we were sloppy on that. Kenji was feeling strong about
and Walter and I didn'
On Wednesday, 27 February 2013 at 00:01:31 UTC, Andrei
Alexandrescu wrote:
I understand how you see it, and honestly could see it from a
mile. When a post (a) cherry-picks all negatives and (b) has a
final tone that mentions no possible solution - it's a foregone
conclusion that no amount of
On Tuesday, 26 February 2013 at 23:37:57 UTC, Andrei Alexandrescu
wrote:
Agreed, but it does happen often that a language feature is
later superseded by a generalization thereof.
Andrei
I agree that this does happen. The question is how the language
evolve with that in mind. Do we choose
On Tuesday, 26 February 2013 at 19:53:11 UTC, Walter Bright wrote:
On 2/25/2013 11:56 PM, foobar wrote:
DDoc isn't part of the language but rather part of the
compiler, nevertheless it
has its downsides. [...]
unittest is worse,
I think you're missing something gigantic. Before
On Tuesday, 26 February 2013 at 18:41:24 UTC, Andrej Mitrovic
wrote:
On 2/26/13, foobar wrote:
Rust on the other hand already
integrated an ownership system and is already far ahead of D's
design.
Far ahead? It allows things like local variables shadowing
earlier declarations:
On Tuesday, 26 February 2013 at 10:59:41 UTC, Dicebot wrote:
I agree with all but small comment on unit tests : current
approach makes it really easy to start adding tests for
projects that do not have them and this is huge. So having
"unittest" blocks themselves is really a success feature.
T
On Monday, 25 February 2013 at 22:26:33 UTC, Walter Bright wrote:
On 2/25/2013 2:00 PM, foobar wrote:
On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright
wrote:
By baking one scheme into the language, people will rarely
feel a need to
reinvent the wheel, and will go on to more
On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
On 2/24/13, Jonathan M Davis wrote:
Yeah, which just adds the confusion, because all it does is
enable debug
bocks.
The feature almost doesn't pay its weight. I mean technically
On Monday, 14 January 2013 at 10:33:56 UTC, mist wrote:
On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau
wrote:
Am Fri, 11 Jan 2013 18:54:12 +0100
schrieb "mist" :
Short comment about cherry pick - it is only bad in sense
that it
creates separate untrackable commit with same content
On Saturday, 12 January 2013 at 12:20:21 UTC, Johannes Pfau wrote:
Am Sat, 12 Jan 2013 09:22:27 +0100
schrieb "foobar" :
[...]
Regarding pull requests targeting master, the current model
*is* geared around that. Most contributions _should_ go to
master (aka devel) and go throug
On Friday, 11 January 2013 at 18:03:33 UTC, mist wrote:
My understanding is that your understanding is somewhat
different from initial proposal but that is where discussion
has flow to since then and that makes me sad :)
They very reason to have staging is to have better replacement
to beta p
On Thursday, 3 January 2013 at 22:04:28 UTC, Jonathan M Davis
wrote:
On Thursday, January 03, 2013 21:42:37 Johannes Pfau wrote:
What I am most concerned about are the timespans discussed:
"I propose to go for a yearly release of the
stable branches with one year support (In the beginning)."
Th
On Thursday, 3 January 2013 at 20:42:39 UTC, Johannes Pfau wrote:
Am Thu, 03 Jan 2013 21:17:08 +0100
schrieb "Rob T" :
On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei
Alexandrescu wrote:
> On 1/3/13 1:58 PM, Walter Bright wrote:
>> As I suggested to Jacob, if the wiki lists git command
>>
On Tuesday, 25 December 2012 at 19:44:41 UTC, Walter Bright wrote:
On 12/25/2012 11:19 AM, Jonathan M Davis wrote:
On Tuesday, December 25, 2012 04:18:10 Walter Bright wrote:
On 12/25/2012 3:41 AM, Jonathan M Davis wrote:
I think that that's what most of us are agreed upon at this
point. What
On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 6:44 AM, foobar wrote:
Using an all encompassing "algorithms" module is also
unhelpful as all
code is essentially an algorithm to accomplish some task. This
is akin
to opening a store called - &q
On Saturday, 22 December 2012 at 23:04:47 UTC, Andrei
Alexandrescu wrote:
On 12/22/12 5:10 PM, foobar wrote:
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg
wrote:
On 2012-12-21 18:05, Andrei Alexandrescu wrote:
s/remove/integrate/
s/ugly/awesome/
It's ugly that the
On Friday, 21 December 2012 at 18:31:48 UTC, Sönke Ludwig wrote:
Am 21.12.2012 18:05, schrieb Andrei Alexandrescu:
(...)
The cheat sheet in std.algorithm is unnecessary (though I
liked the brief examples), but there's a
lot of value in the symbols grouped by category (searching,
comparison, .
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg wrote:
On 2012-12-21 18:05, Andrei Alexandrescu wrote:
s/remove/integrate/
s/ugly/awesome/
It's ugly that they are manually created. Over 300 lines of
comments that the doc generator should be doing automatically.
I would say that
On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understa
On Thursday, 20 December 2012 at 20:58:40 UTC, Benjamin Thaut
wrote:
Am 20.12.2012 20:12, schrieb foobar:>
> This argument is false.
>
> With the current "usual" design:
> Base instance = new Derived();
> instance.method(); // #1
>
> With Beta des
On Thursday, 20 December 2012 at 19:46:25 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2012 at 08:30:36PM +0100, foobar wrote:
On Thursday, 20 December 2012 at 14:51:31 UTC, Dan wrote:
[...]
>I think it is more than syntactic sugar and in this case it is
>trivial because you as a designer o
On Thursday, 20 December 2012 at 14:51:31 UTC, Dan wrote:
On Thursday, 20 December 2012 at 07:48:12 UTC, foobar wrote:
This is trivially implemented with a simple OO design pattern
in any usual OO language:
class Base {
public override precious() {...}
private void myPrecious
On Thursday, 20 December 2012 at 10:15:47 UTC, Benjamin Thaut
wrote:
Am 20.12.2012 10:44, schrieb sclytrack:
@mustcallbefore @mustcallafter
Would these be automatically called in all derived versions?
@autocallbefore @autocallafter
I think @mustcall would suffice, because it won't compil
On Thursday, 20 December 2012 at 10:22:56 UTC, Benjamin Thaut
wrote:
Am 20.12.2012 10:44, schrieb sclytrack:
I guess in the polite version you would make the call to the
derived
version here. The derived version wouldn't have to call super
or anything.
The problem I have with the inner me
On Thursday, 20 December 2012 at 08:12:54 UTC, Paulo Pinto wrote:
On Thursday, 20 December 2012 at 07:48:12 UTC, foobar wrote:
On Thursday, 20 December 2012 at 00:07:49 UTC, H. S. Teoh
wrote:
On Thu, Dec 20, 2012 at 12:11:34AM +0100, Andrej Mitrovic
wrote:
Some interesting blog post:
http
On Thursday, 20 December 2012 at 05:33:27 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
Personally, I think the whole pre-development stage needs to
get looks at -
Specifically having some sort of at least high-level *binding*
planning - road map, mile
On Thursday, 20 December 2012 at 00:07:49 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2012 at 12:11:34AM +0100, Andrej Mitrovic wrote:
Some interesting blog post:
http://journal.stuffwithstuff.com/2012/12/19/the-impoliteness-of-overriding-methods/
It's a post about a common problem in class design,
On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu
wrote:
On 12/19/12 4:40 PM, deadalnix wrote:
>On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
>Alexandrescu wrote:
>>On 12/19/12 4:23 PM,
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" bra
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. Stable isn't a boolean criteria. You'll find different
degree of stability going from not so stable (dev version)
On Wednesday, 19 December 2012 at 17:17:34 UTC, Dmitry Olshansky
wrote:
12/19/2012 1:33 AM, Walter Bright пишет:
On 12/18/2012 11:58 AM, Dmitry Olshansky wrote:
The same bytecode then could be be used for external
representation.
Sigh, there is (again) no point to an external bytecode.
BTW
On Wednesday, 19 December 2012 at 08:45:20 UTC, Walter Bright
wrote:
On 12/19/2012 12:19 AM, Max Samukha wrote:
Evidently you've dismissed all of my posts in this thread on
that topic :-)
As you dismissed all points in favor of bytecode.
And I gave detailed reasons why.
Such as it being a
s
On Tuesday, 18 December 2012 at 00:48:40 UTC, Walter Bright wrote:
Wow, I think that's exactly what we could use! It serves
multiple optional use
cases all at once!
Was there a technical reason for you not getting around
towards implementing, or
just a lack of time?
There always seemed som
On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as minimal and
stupid variation of
module where symbols are ide
On Tuesday, 18 December 2012 at 00:15:04 UTC, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 02:08:55AM +0400, Dmitry Olshansky
wrote:
[...]
I suspect it's one of prime examples where UNIX philosophy of
combining a bunch of simple (~ dumb) programs together in
place of
one more complex program was
On Tuesday, 18 December 2012 at 07:36:26 UTC, Marcel wrote:
Rust designers seems to love really short keywords, this is in
my opinion a bit silly. On the other hand in D you have
keywords like "immutable" that are rather long to type. So I
prefer a mid way between those two.
They aren't silly
On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
On 12/17/2012 1:53 PM, Rob T wrote:
I mentioned in a previous post that we should perhaps focus on
making the .di
concept more efficient rather than focus on obfuscation.
We're not going to do obfuscation, because as I explaine
On Monday, 17 December 2012 at 22:02:45 UTC, foobar wrote:
On Monday, 17 December 2012 at 21:03:04 UTC, Rob T wrote:
On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
At the moment we may use git commands but really we are still
developing on mostly a subversion model. Walter used to
On Monday, 17 December 2012 at 21:03:04 UTC, Rob T wrote:
On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
At the moment we may use git commands but really we are still
developing on mostly a subversion model. Walter used to accept
patches and those were simply replaced by pull
On Monday, 17 December 2012 at 04:49:46 UTC, Michel Fortin wrote:
On 2012-12-17 03:18:45 +, Walter Bright
said:
Whether the file format is text or binary does not make any
fundamental difference.
I too expect the difference in performance to be negligible in
binary form if you maintain
On Monday, 17 December 2012 at 17:45:12 UTC, David Nadlinger
wrote:
On Monday, 17 December 2012 at 17:31:45 UTC, foobar wrote:
Huh?
Both LLVM and KDE are developed on *subversion* and as such
their work-flows are not applicable. Not to mention that KDE
is vastly different in concept and goals
On Sunday, 16 December 2012 at 23:18:20 UTC, Jonathan M Davis
wrote:
On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
Right now we're using a tagging system for releases, implying
releases
are just snapshots of a continuum. But what we need is e.g. to
be able
to patch 2.065 to f
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open
source pr
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu
wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope
that
people promoting that idea don't plan to reproduce ub
On Wednesday, 12 December 2012 at 21:05:05 UTC, Walter Bright
wrote:
On 12/12/2012 2:53 AM, foobar wrote:
One example that comes to mind is the
future version of JavaScript is implemented in ML.
Um, there are many implementations of Javascript. In fact, I
have implemented it in both C++ and
On Wednesday, 12 December 2012 at 19:28:54 UTC, Rob T wrote:
The beta foobar speaks of is actually a combined alpha+beta,
--rt
No. I have already addressed this point before.
Alpha is not part of the _official_ release process.
As a developer I can create my own local branch "DMD-new_fe
On Wednesday, 12 December 2012 at 18:33:17 UTC, Jesse Phillips
wrote:
On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
To summarize:
2. The version scheme is meaningless. Please check out
http://www.mozilla.org/en-US/firefox/channel/#firefox as an
example. It's perfectly
On Wednesday, 12 December 2012 at 18:25:10 UTC, Rob T wrote:
On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
To summarize:
2. The version scheme is meaningless. Please check out
http://www.mozilla.org/en-US/firefox/channel/#firefox as an
example. It's perfectly clear, yo
On Wednesday, 12 December 2012 at 10:35:26 UTC, Walter Bright
wrote:
On 12/12/2012 2:33 AM, foobar wrote:
This isn't a perfect solutions
since the compiler has builtin knowledge about int and does
optimizations that
will be lost with a library type.
See my reply to bearophile about
On Wednesday, 12 December 2012 at 00:51:19 UTC, Walter Bright
wrote:
On 12/11/2012 3:44 PM, foobar wrote:
Thanks for proving my point. after all , you are a C++
developer, aren't you? :)
No, I'm an assembler programmer. I know how the machine works,
and C, C++, and D map onto t
On Wednesday, 12 December 2012 at 00:43:39 UTC, H. S. Teoh wrote:
On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile
wrote:
>foobar:
>
>>I would enforce overflow and underflow checking semantics.<
>
>Plus o
On Wednesday, 12 December 2012 at 01:03:59 UTC, Rob T wrote:
On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
By support I meant specifically _bug fixes_. You can already
download all previous released versions from the website and
in no way am I arguing to change that policy.
Even
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile wrote:
foobar:
I would enforce overflow and underflow checking semantics.<
Plus one or two switches to disable such checking, if/when
someone wants it, to regain the C performance. (Plus some
syntax way to disable/enable s
On Tuesday, 11 December 2012 at 22:08:15 UTC, Walter Bright wrote:
On 12/11/2012 10:44 AM, foobar wrote:
All of the above relies on the assumption that the safety
problem is due to the
memory layout. There are many other programming languages that
solve this by
using a different point of view
On Tuesday, 11 December 2012 at 19:57:55 UTC, Rob T wrote:
On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
First of all - Yay!
There are still a few open questions that need to be decided
before a suitable process can be defined.
I'd say we should _at most_
support _one_ pre
On Tuesday, 11 December 2012 at 16:09:14 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 8:24 AM, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just
allow the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b +
On Tuesday, 11 December 2012 at 16:35:39 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 11:29 AM, eles wrote:
There's a lot to be discussed on the issue. A few quick
thoughts:
* 32-bit integers are a sweet spot for CPU architectures.
There's
rarely a provision for 16- or 8-bit operations; the ac
On Tuesday, 11 December 2012 at 02:02:54 UTC, Andrei Alexandrescu
wrote:
On 12/10/12 7:19 PM, H. S. Teoh wrote:
Sounds OK to me, though it seems unnecessarily complicated.
FWIW there's also this:
http://drewfradette.ca/a-simpler-successful-git-branching-model/
Andrei
First of all - Yay!
On Wednesday, 5 December 2012 at 16:21:55 UTC, Jonathan M Davis
wrote:
On Wednesday, December 05, 2012 15:11:55 foobar wrote:
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
wrote:
> On Tuesday, December 04, 2012 17:35:23 foobar wrote:
>> That's a lot of duplication
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
wrote:
On Tuesday, December 04, 2012 17:35:23 foobar wrote:
That's a lot of duplication considering D already provides this
in Object.
Though per the last major discussion on const-correctness and
Object, it's
likely tha
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
wrote:
On Tuesday, December 04, 2012 17:35:23 foobar wrote:
That's a lot of duplication considering D already provides this
in Object.
Though per the last major discussion on const-correctness and
Object, it's
likely tha
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
wrote:
On Tuesday, December 04, 2012 17:35:23 foobar wrote:
That's a lot of duplication considering D already provides this
in Object.
Though per the last major discussion on const-correctness and
Object, it's
likely tha
On Tuesday, 4 December 2012 at 13:47:39 UTC, Paulo Pinto wrote:
Generally speaking you are right. But specifically regarding
toString, what would you suggest?
Should each and every Interface have a toString method?
Yes for each interface where you intend to call toString().
That's a lot of
On Tuesday, 4 December 2012 at 12:30:29 UTC, Paulo Pinto wrote:
On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg
wrote:
On 2012-12-04 09:22, Maxim Fomin wrote:
And what happens if nobody implements an interface?
import std.stdio;
interface I { }
class A { }
void main()
{
I i;
On Tuesday, 4 December 2012 at 07:38:31 UTC, Maxim Fomin wrote:
On Monday, 3 December 2012 at 23:53:26 UTC, deadalnix wrote:
On Monday, 3 December 2012 at 21:53:47 UTC, Walter Bright
wrote:
I really don't know what issue you're trying to solve here.
The typeid's work fine - and interfaces are n
On Monday, 3 December 2012 at 20:59:24 UTC, Walter Bright wrote:
On 12/4/2012 2:52 AM, Jacob Carlborg wrote:
Note, I'm not saying that an interface should be implicitly
converted to
any class, only to Object.
But not all interfaces come from Objects.
IMO this is a design mistake - the spec
On Thursday, 29 November 2012 at 23:02:17 UTC, Walter Bright
wrote:
On 11/30/2012 9:43 AM, Walter Bright wrote:
It is possible for each static constructor to specify
independently of
the other static constructors which imports must be
constructed first.
But do we really want to go that far?
On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei
Alexandrescu wrote:
On 11/29/12 6:44 AM, foobar wrote:
On Thursday, 29 November 2012 at 10:25:40 UTC, Walter Bright
wrote:
On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
On 2012-11-29 03:00, Walter Bright wrote:
An attribute would bring
would be
global to the module.
Why can't the attribute be global to the module?
Because attributes attach to the declarations they enclose. A
global attribute would be something else.
What's wrong with attaching the annotation to the module
declaration?
i.e.
@no_circular_ctors mod
On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:
On 29 November 2012 03:48, deadalnix
wrote:
On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M
Davis wrote:
Since master will almost certainly be the development branch,
I don't see
how
that's a problem. The stable branch
On Saturday, 17 November 2012 at 13:22:23 UTC, Michel Fortin
wrote:
On 2012-11-16 18:56:28 +, Dmitry Olshansky
said:
11/16/2012 5:17 PM, Michel Fortin пишет:
In case you want to protect two variables (or more) with the
same mutex.
For instance:
Mutex m;
synchronized(m) int next
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
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 of
On Wednesday, 7 November 2012 at 08:36:49 UTC, Jacob Carlborg
wrote:
On 2012-11-06 22:53, Walter Bright wrote:
C++11 has had problems adding new keywords, as about every
identifier
somewhere has been used by someone's C++ source code, and they
don't
want to break existing code. So C++11 winds
On Tuesday, 6 November 2012 at 20:01:27 UTC, Jacob Carlborg wrote:
On 2012-11-06 20:52, Manu wrote:
I'd like to re-enforce the consideration that @attribute()
makes it
looks like they affect the code generation somehow... they're
really
just annotations.
I still like the syntax.
I'd also l
On Saturday, 20 October 2012 at 21:16:44 UTC, foobar wrote:
On Saturday, 20 October 2012 at 21:03:20 UTC, H. S. Teoh wrote:
On Sat, Oct 20, 2012 at 04:39:28PM -0400, Nick Sabalausky
wrote:
On Sat, 20 Oct 2012 14:59:27 +0200
"foobar" wrote:
> On Saturday, 20 October 2012 at 10:51:
On Saturday, 20 October 2012 at 21:03:20 UTC, H. S. Teoh wrote:
On Sat, Oct 20, 2012 at 04:39:28PM -0400, Nick Sabalausky wrote:
On Sat, 20 Oct 2012 14:59:27 +0200
"foobar" wrote:
> On Saturday, 20 October 2012 at 10:51:25 UTC, Denis
> Shelomovskij
> wrote:
> >
>
On Saturday, 20 October 2012 at 10:51:25 UTC, Denis Shelomovskij
wrote:
18.10.2012 12:58, foobar пишет:
IMO, this is a redundant feature that complicates the language
for no
benefit and should be deprecated.
strings already have an escape sequence for specifying
code-points "\u"
foobar(Foo f)
{
f.func();
}
---
If D had C++'s "private", that restriction would make a lot of
sense
(except possibly for nested classes, but I dunno). That's
because: How
can you override a class you can't even access?
But D doesn't have a &
On Friday, 19 October 2012 at 18:46:07 UTC, foobar wrote:
On Friday, 19 October 2012 at 15:07:44 UTC, Don Clugston wrote:
On 19/10/12 16:07, foobar wrote:
On Friday, 19 October 2012 at 13:19:09 UTC, Don Clugston
wrote:
We can still have both (assuming the code points are
valid...):
string
On Friday, 19 October 2012 at 15:07:44 UTC, Don Clugston wrote:
On 19/10/12 16:07, foobar wrote:
On Friday, 19 October 2012 at 13:19:09 UTC, Don Clugston wrote:
We can still have both (assuming the code points are
valid...):
string foo = "\ua1\ub2\uc3"; // no .dup
That doesn
On Friday, 19 October 2012 at 13:19:09 UTC, Don Clugston wrote:
We can still have both (assuming the code points are valid...):
string foo = "\ua1\ub2\uc3"; // no .dup
That doesn't compile.
Error: escape hex sequence has 2 hex digits instead of 4
Come on, "assuming the code points are valid"
On Friday, 19 October 2012 at 00:14:18 UTC, Nick Sabalausky wrote:
On Thu, 18 Oct 2012 12:11:13 +0200
"foobar" wrote:
How often large binary blobs are literally spelled in the
source code (as opposed to just being read from a file)?
Frequency isn't the issue. The issues ar
On Friday, 19 October 2012 at 07:53:30 UTC, Jacob Carlborg wrote:
On 2012-10-19 04:48, Timon Gehr wrote:
Then how to specify that the value of x cannot be escaped?
I'm in favour of doing it the other way round and disallow
escaping of
ref parameters without an unsafe cast.
"scope" is suppos
On Thursday, 18 October 2012 at 14:29:57 UTC, Don Clugston wrote:
On 18/10/12 10:58, foobar wrote:
On Thursday, 18 October 2012 at 02:47:42 UTC, H. S. Teoh wrote:
On Thu, Oct 18, 2012 at 02:45:10AM +0200, bearophile wrote:
[...]
hex strings are useful, but I think they were invented in D1
On Thursday, 18 October 2012 at 10:11:14 UTC, foobar wrote:
On Thursday, 18 October 2012 at 10:05:06 UTC, bearophile wrote:
The docs say:
http://dlang.org/lex.html
Hex strings allow string literals to be created using hex
data. The hex data need not form valid UTF characters.<
This
04 C1 E2";
}
Gives me:
temp.d(2): Error: Outside Unicode code space
Are the docs correct?
------
foobar:
Seems to me this is in the same ballpark as the built-in
complex numbers. Sure it's nice to be able to write "4+5i"
instead of "comple
On Thursday, 18 October 2012 at 09:42:43 UTC, monarch_dodra wrote:
On Thursday, 18 October 2012 at 08:58:57 UTC, foobar wrote:
IMO, this is a redundant feature that complicates the language
for no benefit and should be deprecated.
strings already have an escape sequence for specifying
code
On Thursday, 18 October 2012 at 06:11:26 UTC, monarch_dodra wrote:
On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis
wrote:
On Thursday, October 18, 2012 06:24:08 jerro wrote:
What would be the problem with const ref taking rvalues?
Read the thread that I already linked to:
http
On Thursday, 18 October 2012 at 02:47:42 UTC, H. S. Teoh wrote:
On Thu, Oct 18, 2012 at 02:45:10AM +0200, bearophile wrote:
[...]
hex strings are useful, but I think they were invented in D1
when
strings were convertible to char[]. But today they are an
array of
immutable UFT-8, so I think thi
On Wednesday, 17 October 2012 at 15:16:12 UTC, Andrei
Alexandrescu wrote:
On 10/16/12 2:49 AM, Jacob Carlborg wrote:
On 2012-10-16 02:10, Peter Alexander wrote:
It's cute, but I think it is terribly misleading. I wouldn't
recommend
that to anyone.
I agree. I'm using foo.bar._, that's the sa
On Monday, 15 October 2012 at 17:53:15 UTC, Andrei Alexandrescu
wrote:
On 10/15/12 1:37 PM, foobar wrote:
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei
Alexandrescu wrote:
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu
wrote:
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every module
that wanna defines a moduleMain(string[] args) and then you
have one module main.d that has:
void ma
1 - 100 of 368 matches
Mail list logo
