El 19/10/2011 20:12, dsimcha escribió:
== Quote from Don (nos...@nospam.com)'s article
The hack must go.
No. Something as simple as sqrt(2) must work at all costs, period. A language
that adds a bunch of silly complications to something this simple is
fundamentally
broken. I don't remember
El 20/10/2011 21:37, Martin Nowak escribió:
It just took me over one hour to find out the unthinkable.
foreach(c; str) will deduce c to immutable(char) and doesn't care about
unicode.
Now there is so many unicode transcoding happening in the language that
it starts to get annoying,
but the most b
El 11/12/2011 16:14, Chad J escribió:
On 12/11/2011 08:15 AM, maarten van damme wrote:
...
I think one thing that could would be (optional) reference counting for
transitively atomic types. Of course, this is just another kind of
garbage collection, but it is /deterministic/ and parallelizes w
El 22/12/2011 8:03, Jonathan M Davis escribió:
On Thursday, December 22, 2011 01:53:00 Nick Sabalausky wrote:
If you're a programmer, or even just a power user, you have absolutely no
excuse not to *already* have a 7z-capable program installed.
Christ, even the "least-common-denominator" piracy
El 13/01/2012 21:29, bearophile escribió:
Bioinformatics, exploratory programing, simulations, data munging, hardening of
slow scripts, data visualization, data mining, optimization of some tasks,
faster routines for dynamic code written by other people, and more.
The problem is that often you
El 15/01/2012 20:04, Tobias Pankrath escribió:
I also know that people dislike using reference parameters in C++ due to
the lack of visibility at the call site (causing them to use pointers).
Which is true for me. Every single one of my reference parameters is const
ref or pointer.
swap(ref a
El 17/01/2012 18:24, Andrei Alexandrescu escribió:
On 2012-01-17 06:48:26 +, Andrei Alexandrescu
...
aa.keys is taken btw.
OK, I see, .keys and .values currently return dynamic arrays.
But the most appropriate property name for the above range should indeed
be .keys !
Now, wouldn't
El 17/01/2012 23:32, Timon Gehr escribió:
On 01/17/2012 11:19 PM, Alvaro wrote:
El 17/01/2012 18:24, Andrei Alexandrescu escribió:
On 2012-01-17 06:48:26 +, Andrei Alexandrescu
...
aa.keys is taken btw.
OK, I see, .keys and .values currently return dynamic arrays.
But the most
El 20/01/2012 10:15, Jonathan M Davis escribió:
On Friday, January 20, 2012 09:58:42 Marco Leise wrote:
Ah, I meant to say that getters should not modify their object. When I see
"a = abc.x[i]" I would be a little surprised to find that it changes the
observable state of abc. The same goes for "
El 20/01/2012 18:58, Andrei Alexandrescu escribió:
On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
I vote properties.
The general rule to me the is a function represent
El 21/01/2012 3:05, Michel Fortin escribió:
>>> I think byKey and byValue are oddly named, property or not.
>>
>> Give them better names and convince others. Don't choose "keys"
>> and "values".
>
> Well, if the best ones are already taken, I'd say "allKeys" and
> "allValues" would be the next bes
El 26/01/2012 14:59, Trass3r escribió:
I thought it'd be good to outsource this question from the other thread
about enums as flags.
Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no advantages.
A better example is somet
El 18/01/2012 21:37, Nick Sabalausky escribió:
"Nick Sabalausky" wrote in message
Plus I've spent time in other langauges where using a function name without
parens is the way to refer to a function itself, rather than invoke the
function. That's something I very much like: "foo" refers to the f
The current std.xml needs a replacement (I think it has already been
decided so), something with a familiar DOM API with facilities to
manipulate XML documents.
I needed to do a quick XML file transform and std.xml was of little use.
Then I found this Adam D. Ruppe's library:
https://github.
El 19/12/2011 9:11, Adam Wilson escribió:
1. Function Implementations are removed
What about function inlining? would it work from a different module?
I think the implementation of small functions should be kept so that
client code can inline them.
The current DMD does this apparently, it
El 14/03/2012 22:13, Adam Wilson escribió:
> On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro
> wrote:
>
> The problem is that in DI generation, at least as near as I can tell, D
> has now idea how big a function is during DI generation. In my
> experience it was keeping all functi
El 16/03/2012 14:35, Adam D. Ruppe escribió:
We introduce two new things to the language:
1) the @note(expression) attribute. You can put
as many "notes" on a declaration as you want by
simply listing them.
I like that.
I learned about annotations a couple years ago in two contexts:
- We
El 21/03/2012 19:29, H. S. Teoh escribió:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map["abc"][20]++;
IIRC, that worked fine for me a few weeks ago. And I found it to be just
great that it did. I'll have to re-check bu
El 21/03/2012 19:39, Jonathan M Davis escribió:
On Wednesday, March 21, 2012 11:29:14 H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map["abc"][20]++;
This is understandable, since the compiler translates the second line to
El 26/03/2012 13:58, bearophile escribió:
Issue 3789 is an enhancement request, I think it fixes one small but quite
important problem in D design. The situation is shown by this simple code:
struct String {
char[] data;
}
void main () {
auto foo = String("foo".dup);
auto bar =
El 27/03/2012 22:20, Steven Schveighoffer escribió:
On Mon, 26 Mar 2012 17:25:07 -0400, Alvaro
wrote:
Maybe it makes more sense that struct==struct applies == to each of
its fields. It would be the same as bitwise comparison for simple
primitive types, but would be more useful with other
I agree with Adam's view and I really think @property is a good
thing.
APIs have to specify their semantics and clearly distinguish
properties from functions, which may be implemented similarly but
*mean* different things. Basically a property is a *thing* or a
characteristic, normally a noun
On Saturday, 16 March 2013 at 22:34:01 UTC, Michael wrote:
Why Dmd accepts?
class E
{
@property public static pro(Object v)
{
}
}
My guess is this: If it takes an argument (Object v) I assume it
is a *setter*, so it does not need to return anything. Then, the
non-written type i
D already has a long list of keywords, reserved words can't be used as
identifiers, which can be annoying. "body" in particular is a common
noun that programmers would gladly use as a variable name in physics
simulation, astronomy, mechanics, games, health, etc. I think "body" can
be removed fr
El 25/03/2011 22:40, piotrek escribió:
Speaking of real world examples(is my world really real? :D)
I hit "body" when I was doing an html generator. Long before that when
I was reading language specification I looked with distaste at the "body"
keyword in the contract programming section. Still
El 04/04/2011 23:51, Matthias Pleh escribió:
Am 04.04.2011 23:34, schrieb Daniel Gibson:
Am 04.04.2011 23:27, schrieb Matthias Pleh:
was: [GSoC] Container proposals by Ishan and Christian
[snip]
This were the requirments for the GUI library:
- Corss-platform (Win/linux)
Don't forget Mac O
El 05/04/2011 15:32, Jacob Carlborg escribió:
On 2011-04-05 15:25, Matthias Pleh wrote:
Am 05.04.2011 15:06, schrieb Jacob Carlborg:
On 2011-04-05 13:08, Matthias Pleh wrote:
So I think for short or middle term such solution like gtkD, QtD, DWT
are good, but for the long term the D community n
El 22/04/2011 19:36, Walter Bright escribió:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
I've always been surprised when discussions usually just bring garbage
collection as the only alternative to explicit manual memory management.
I imagined it as a garbage truck that has its own schedu
El 18/05/2012 9:58, Lars T. Kyllingstad escribió:
I remember back when we were considering whether to move DMD, Phobos and
druntime from SVN on DSource to Git on GitHub, there were some concerns
about using Git on Windows. People claimed that Git was a very
Linux-centric tool, and that Windows s
El 06/07/2012 14:31, Andrea Fontana escribió:
I see there's a c-mongo library binding called mongo-d-library on
github, but it's very c-style and complex to use.
I've seen a quite better binding in vibe.d but it seems very difficult
to extract it from vibe.d
Any suggestion?
I'm starting to p
El 22/09/2011 0:17, Walter Bright escribió:
I've collected a few from various languages for comparison:
D
(a,b) { return a + b; }
Ruby
->(a,b) { a + b }
C++0x
[](int a, int b) { return a + b; }
C#
(a,b) => a + b
Scala
(a:Int, b:Int) => a + b
Erlang
fun(a, b) -> a + b end.
Haskell
\a b -> a
Walter Bright Wrote:
> Simen kjaeraas wrote:
> > I'm already in love with this feature.
>
> So am I. It seems to be incredibly powerful.
>
> Looks to me you can do things like:
>
> 1. hook up to COM's IDispatch
>
> 2. create 'classes' at runtime
>
> 3. add methods to existing classes (monkey
Walter Bright Wrote:
> Simen kjaeraas wrote:
> > It would seem Walter is right, but only for opDispatch. This compiles
> > fine. If you want compile errors, move the ellipsis around:
>
> Hmm, looks like there is a problem, but it has nothing to do with
> opDispatch, as this:
>
> void bar(s
33 matches
Mail list logo
