On 1/23/13 2:28 AM, Jacob Carlborg wrote:
On 2013-01-22 20:51, Andrei Alexandrescu wrote:
Not at all, I'd say. CTFE has a much lower cost of learning - you only
need to know which subset of D is allowed. Maybe you meant code mixins?
To be able to use AST macros one needs CTFE. One needs funct
On 2013-45-23 04:01, deadalnix wrote:
On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas wrote:
One could argue that the compiler should choose the other constructor,
and
even that having default constructors is reasonable. However, D has gone
the route of not having default const
On Wednesday, 23 January 2013 at 07:33:22 UTC, eles wrote:
On Wednesday, 23 January 2013 at 06:22:55 UTC, Philippe Sigaud
wrote:
With D, we aim for one bug every 14 lines of code :)
Add to that the fact that programs in D tend to be shorter than
their C or even C++ equivalents!
Less boiler
On 1/23/13 2:41 AM, Jacob Carlborg wrote:
On 2013-01-22 20:53, Sönke Ludwig wrote:
Consider "int[4u] delegate(scope float*[void function(scope int)] p1,
Rebindable!(const(C))*[]* b)"
There are actually quite some things to parse in human readable type
strings, I even remember some
expressions.
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
But the trend is C is becoming more and more a high-level
assembler.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
This blog post (the first in a series of three) tries to explain
some of these issues s
On Wednesday, 23 January 2013 at 07:57:10 UTC, Andrei
Alexandrescu wrote:
Martin Odersky confessed to me being quite worried about the
possible community reaction to the introduction of AST macros.
I haven't kept close tabs to see how it's turning out.
Can he or you explain why ?
I complete
On Wednesday, 23 January 2013 at 08:00:05 UTC, Simen Kjaeraas
wrote:
On 2013-45-23 04:01, deadalnix wrote:
On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas
wrote:
One could argue that the compiler should choose the other
constructor, and
even that having default constructors is r
On Tuesday, 22 January 2013 at 21:14:21 UTC, Freddie Chopin wrote:
On Tuesday, 22 January 2013 at 21:02:32 UTC, Paulo Pinto wrote:
I don't really have much embedded experience besides assembly
programming in the old days (Z80, M68000, x86, MIPS, self
build processor for digital circuits class).
On 1/22/2013 11:53 PM, Andrei Alexandrescu wrote:
On 1/23/13 2:18 AM, Jacob Carlborg wrote:
On 2013-01-22 20:47, Andrei Alexandrescu wrote:
Not sure I understand. We have working templates that produce passable
PDF via LaTeX.
It's somewhat cheating to use an intermediate language like LaTeX,
On Wednesday, 23 January 2013 at 07:57:38 UTC, Era Scarecrow
wrote:
On Wednesday, 23 January 2013 at 07:33:22 UTC, eles wrote:
On Wednesday, 23 January 2013 at 06:22:55 UTC, Philippe Sigaud
wrote:
Plenty of stuff that simplifies a whole lot of stuff. D is
indeed the language I always wanted :)
On Wednesday, 23 January 2013 at 04:56:11 UTC, deadalnix wrote:
On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow
wrote:
It's been quoted that for every 10 lines of code there's a bug.
It is said a lot. I'd like to see hard data on that one. I'd
bet that it greatly vary from one prog
On 2013-43-23 09:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 08:00:05 UTC, Simen Kjaeraas wrote:
On 2013-45-23 04:01, deadalnix wrote:
On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas wrote:
One could argue that the compiler should choose the other
constructor, and
On Wednesday, 23 January 2013 at 10:28:05 UTC, Simen Kjaeraas
wrote:
NonNull!T bar = something;
foo(move(bar));
bar; // bar is null \o/
Except it isn't.
move memcopy T.init . So it will be null.
On 2013-48-23 11:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:28:05 UTC, Simen Kjaeraas wrote:
NonNull!T bar = something;
foo(move(bar));
bar; // bar is null \o/
Except it isn't.
move memcopy T.init . So it will be null.
Try it. Without a destructor, move does not revert to T
H. S. Teoh wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=9372
Now I have to use a dummy argument to my class ctor, just becauseit
happens to have a member that has a @disabled ctor. :-/
At least
Trouble t = void;
should work. But it does not! :-/
Peter
Why is it required to have the .init property? Where is it useful
and why was this decision made?
On Wednesday, 23 January 2013 at 06:28:14 UTC, Philippe Sigaud
wrote:
Since 2.061, I have a small script that downloads dmd, druntime
and phobos from github and runs make. I worked flawlessly for
the past two weeks, but since Sunday, g++ chokes on json.c:
g++ -m32 -c -Wno-deprecated -Wstrict-
On Wednesday, 23 January 2013 at 11:03:45 UTC, Minas Mina wrote:
Why is it required to have the .init property? Where is it
useful and why was this decision made?
.init is very useful in the sense that it represents the raw
object, *statically*.
This is useful for declaring statics.
It also
On Wednesday, 23 January 2013 at 10:55:43 UTC, Simen Kjaeraas
wrote:
On 2013-48-23 11:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:28:05 UTC, Simen Kjaeraas
wrote:
NonNull!T bar = something;
foo(move(bar));
bar; // bar is null \o/
Except it isn't.
move memcopy T.init . So it w
On Wednesday, 23 January 2013 at 09:46:47 UTC, Don wrote:
"There has been no error reported in TeX since 1994 or 1995"
-- Knuth, 2002.
There were 7 bugs in TeX reported between 1982 and 1995.
Tex has a lot more than 70 lines of code :-)
Bugs in code don't always live on one line per bug; The
On 2013-14-23 13:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:55:43 UTC, Simen Kjaeraas wrote:
On 2013-48-23 11:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:28:05 UTC, Simen Kjaeraas wrote:
NonNull!T bar = something;
foo(move(bar));
bar; // bar is null \o/
Except
On Wednesday, 23 January 2013 at 13:26:47 UTC, Simen Kjaeraas
wrote:
On 2013-14-23 13:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:55:43 UTC, Simen Kjaeraas
wrote:
On 2013-48-23 11:01, deadalnix wrote:
On Wednesday, 23 January 2013 at 10:28:05 UTC, Simen
Kjaeraas wrote:
NonNul
On 1/21/13 10:06 PM, H. S. Teoh wrote:
On Mon, Jan 21, 2013 at 09:03:55PM -0500, Andrei Alexandrescu wrote:
On 1/21/13 3:06 PM, H. S. Teoh wrote:
I have to admit that ddoc hasn't really done it for me (yet). I think
the impediment is that the default output needs some work (mainly in
CSS and in
On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote:
[...]
> Anyway, I do strongly feel like we should stop adding more stuff
> now. Too much stuff is here already, some already start to misbehave
> together. It is probably time to consolidate the language, and keep
> that kind of stuff for a
On Wednesday, 23 January 2013 at 15:36:16 UTC, H. S. Teoh wrote:
On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote:
[...]
Anyway, I do strongly feel like we should stop adding more
stuff
now. Too much stuff is here already, some already start to
misbehave
together. It is probably time t
On 2013-01-23 08:50, Walter Bright wrote:
If your program has undefined behavior in it, the -O flag can definitely
cause that behavior to change.
Yes, I guess that is to be expected. I'm mostly talking about correct
code here.
--
/Jacob Carlborg
On 2013-01-23 08:58, Andrei Alexandrescu wrote:
If we need a secondary parser to slice and dice the json output, we
failed producing good json output.
That's what I'm saying. Just use what Rainer suggested:
"type" : {
"mangled" : "PPPi",
"pretty" : "int***",
}
--
/Jacob Carlborg
On 1/23/13 11:07 AM, Jacob Carlborg wrote:
On 2013-01-23 08:58, Andrei Alexandrescu wrote:
If we need a secondary parser to slice and dice the json output, we
failed producing good json output.
That's what I'm saying. Just use what Rainer suggested:
"type" : {
"mangled" : "PPPi",
"pretty" :
On Wednesday, 23 January 2013 at 12:07:48 UTC, monarch_dodra
wrote:
On Wednesday, 23 January 2013 at 11:03:45 UTC, Minas Mina wrote:
Why is it required to have the .init property? Where is it
useful and why was this decision made?
.init is very useful in the sense that it represents the raw
o
I was using dur, and as powerful as it is, I *hate* typing:
//
Thread.sleep(dur!"msecs"(100));
//
Then, this reminded me of an older thread I started:
Neat: UFCS for integer dot operator suffix
http://forum.dlang.org/thread/uchcycnsvykuojzhu...@forum.dlang.org
And then it struct me:
//-
On 01/23/2013 05:07 PM, Jacob Carlborg wrote:
On 2013-01-23 08:58, Andrei Alexandrescu wrote:
If we need a secondary parser to slice and dice the json output, we
failed producing good json output.
That's what I'm saying. Just use what Rainer suggested:
"type" : {
"mangled" : "PPPi",
On 01/23/2013 06:03 PM, monarch_dodra wrote:
...
Well, if you are compiling with "-property", the compiler forces you to
...
So don't.
AFAIK, the "-property" switch enforces that non-property functions use parenthesis, so
removing an "@property" attribute is potentially breaking. The opposi
On 01/23/2013 09:13 AM, Timon Gehr wrote:
> On 01/23/2013 06:03 PM, monarch_dodra wrote:
>> ...
>>
>> Well, if you are compiling with "-property", the compiler forces you to
>> ...
>
> So don't.
>
>> AFAIK, the "-property" switch enforces that non-property functions use
>> parenthesis, so removing
On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
That is completely nonsensical behaviour. Just ignore -property.
Amen! -property MUST die. @property should fix the real problems
with properties, not leave that broken while adding new problems.
On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
> On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> >That is completely nonsensical behaviour. Just ignore -property.
>
>
> Amen! -property MUST die. @property should fix the real problems
> with properties, not leave
23-Jan-2013 21:13, Timon Gehr пишет:
On 01/23/2013 06:03 PM, monarch_dodra wrote:
...
Well, if you are compiling with "-property", the compiler forces you to
...
So don't.
AFAIK, the "-property" switch enforces that non-property functions use
parenthesis, so removing an "@property" attribut
On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
> So I thought I'd discuss: Would there be a reason to not make dur
> a property? This should impact no-one, but make ufcs usage that
> much more convenient. Can I get the go-ahead to make and document
> the change?
No. It's not conceptu
On Wednesday, 23 January 2013 at 17:47:44 UTC, H. S. Teoh wrote:
I'm starting to think that perhaps @property should be disposed
of completely.
There is a problem @property can potentially solve: a property
returning a callable.
alias void delegate() Callable;
struct test {
@property Cal
On Wed, 23 Jan 2013 18:03:19 +0100
"monarch_dodra" wrote:
> I was using dur, and as powerful as it is, I *hate* typing:
>
> //
> Thread.sleep(dur!"msecs"(100));
> //
>
I completely agree. It's absolutely hideous. And the flexibility of
having the unit be a template param is only rarely
Am Wed, 23 Jan 2013 09:45:49 -0800
schrieb "H. S. Teoh" :
> On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
> > On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> > >That is completely nonsensical behaviour. Just ignore -property.
> >
> >
> > Amen! -property MUST d
Am Wed, 23 Jan 2013 19:08:09 +0100
schrieb "Adam D. Ruppe" :
>
> My preferred solution is:
>
> 1) all functions without @property work exactly the same way they
> do now (optional parenthesis, callable as setters with =)
>
> 2) all functions with @property are ALWAYS rewritten so that a
> ref
On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
wrote:
This sounds OK, but you can still run into the callable issue
if a normal function returns a callable.
I don't think so because delegates require the parens to call
anyway, and so do opCall objects (without the parens, it is j
On Wed, 23 Jan 2013 09:45:49 -0800
"H. S. Teoh" wrote:
> On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
> > On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> > >That is completely nonsensical behaviour. Just ignore -property.
> >
> >
> > Amen! -property MUST die
On Wed, 23 Jan 2013 19:40:02 +0100
"Adam D. Ruppe" wrote:
> On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
> wrote:
> > This sounds OK, but you can still run into the callable issue
> > if a normal function returns a callable.
>
> I don't think so because delegates require the pa
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis
wrote:
We have aliases already. If you don't like dur!"msecs"(100),
you can do
msecs(100). The same with days, minutes, etc.
- Jonathan M Davis
Hum. I guess I missed those. Thanks.
On Wed, 23 Jan 2013 13:57:32 -0500
Nick Sabalausky wrote:
>
> void delegate() {...} bar;
Erm, obviously I meant:
void delegate() bar = ...;
23-Jan-2013 22:57, Nick Sabalausky пишет:
On Wed, 23 Jan 2013 19:40:02 +0100
"Adam D. Ruppe" wrote:
On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
wrote:
This sounds OK, but you can still run into the callable issue
if a normal function returns a callable.
I don't think so bec
On Wed, 2013-01-23 at 02:57 -0500, Andrei Alexandrescu wrote:
[…]
> Martin Odersky confessed to me being quite worried about the possible
> community reaction to the introduction of AST macros. I haven't kept
> close tabs to see how it's turning out.
AST transforms are working wonderfully well i
On Wednesday, 23 January 2013 at 18:57:38 UTC, Nick Sabalausky
wrote:
So you want it to work like this?:
Yes, keeping the current behavior unless you opt-in to @property
(though I wouldn't object to Dmitry's idea of "error: expression
has no effect").
If I update dmd again and get 1,000 use
Am Wed, 23 Jan 2013 19:40:02 +0100
schrieb "Adam D. Ruppe" :
> On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
> wrote:
> > This sounds OK, but you can still run into the callable issue
> > if a normal function returns a callable.
>
> I don't think so because delegates require the
On Wed, 23 Jan 2013 23:03:32 +0400
Dmitry Olshansky wrote:
> 23-Jan-2013 22:57, Nick Sabalausky пишет:
> > On Wed, 23 Jan 2013 19:40:02 +0100
> > "Adam D. Ruppe" wrote:
> >
> >> On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
> >> wrote:
> >>> This sounds OK, but you can still run i
On Wednesday, 23 January 2013 at 19:18:09 UTC, Johannes Pfau
wrote:
int DG() {return 42};
int delegate() getDG() {return &DG};
auto dg = getDG; //OK
auto ??? = getDG();
The last line could be a call to getDG with optional
parenthesis,
so ??? = DG. Or it could be a call to getDG without option
On Wednesday, 23 January 2013 at 19:29:44 UTC, Nick Sabalausky
wrote:
int foo() {...}
int delegate() {...} bar;
auto x = foo; // call it
auto y = bar; // don't call it
I don't have a problem with that because delegates and functions
are different beasts anyway. For one major example, you can'
>
> Run make clean first.
>
>
Ohhh, that worked perfectly! Thanks a lot!
On 2013-01-23 08:53, Andrei Alexandrescu wrote:
No, it's not cheating at all. You do realize the enormous effort that
would be involved in producing good quality typesetting?
I'm not even arguing.
--
/Jacob Carlborg
On 2013-01-23 18:09, Timon Gehr wrote:
That still requires at least one of two secondary parsers.
Technically yes, but there's already a demangler available in
Phobos/druntime.
--
/Jacob Carlborg
On 1/23/2013 8:06 AM, Jacob Carlborg wrote:
On 2013-01-23 08:50, Walter Bright wrote:
If your program has undefined behavior in it, the -O flag can definitely
cause that behavior to change.
Yes, I guess that is to be expected. I'm mostly talking about correct code here.
-O can especially ex
On 1/23/13 1:18 PM, Johannes Pfau wrote:
Please do not forget the main reason for @property: Returning a
delegate from a function can become ambiguous without it:
int a(){return 42;}
void b() {return&a;}
auto var = b; //OK
auto var2 = b(); //is var2 == b or == 42?
It might be an extreme corner
On 1/23/13 1:48 PM, Nick Sabalausky wrote:
Having the *caller* decide whether something is a property or not makes
as much sense as having the caller decide the function's name,
signature and semantics.
No. The caller does get to decide a variety of syntactic aspects of the
invocation.
If a
On 1/23/13 2:08 PM, Russel Winder wrote:
There is no doubt that AST transforms in Groovy is not something the
application programmer would spend time on unless they knew what they
were doing. It isn't a trivial API. However it is straightforward once
you know ASTs.
Given the richness of today's
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis
wrote:
On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
So I thought I'd discuss: Would there be a reason to not make
dur
a property? This should impact no-one, but make ufcs usage that
much more convenient. Can I get t
On 2013-01-23 08:57, Andrei Alexandrescu wrote:
I completely disagree. (Sorry to foul you twice.) All AST macro systems
I've studied are considerably difficult to understand and use
effectively. By comparison, string macros are brutal and unstructured
but the kind of thing all programmer worth t
On 1/23/13, Adam D. Ruppe wrote:
> On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> Amen! -property MUST die. @property should fix the real problems
> with properties, not leave that broken while adding new problems.
About @property problems, I've recently ran into this:
ModuleI
On 2013-01-23 18:03, monarch_dodra wrote:
I was using dur, and as powerful as it is, I *hate* typing:
//
Thread.sleep(dur!"msecs"(100));
//
Then, this reminded me of an older thread I started:
Neat: UFCS for integer dot operator suffix
http://forum.dlang.org/thread/uchcycnsvykuojzhu...@
On 2013-01-23 19:18, Johannes Pfau wrote:
It might be an extreme corner case, but it's inconsistent behavior and
confusing. Need a real-world example?
http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
(with proper @property the first examp
On 2013-01-23 19:08, Adam D. Ruppe wrote:
My preferred solution is:
1) all functions without @property work exactly the same way they do now
(optional parenthesis, callable as setters with =)
2) all functions with @property are ALWAYS rewritten so that a reference
to them instead references th
On 2013-01-23 19:48, Nick Sabalausky wrote:
Having the *caller* decide whether something is a property or not makes
as much sense as having the caller decide the function's name,
signature and semantics.
In Ruby parentheses are optional when calling a method. I have never had
any problem with
On Wednesday, January 23, 2013 21:33:07 Jacob Carlborg wrote:
> This is how it should look like. Date ranges in Ruby on Rails can be
> really beautiful:
>
> date = 2.days.ago
>
> I think we should have the same in D.
I confess that it's syntax like that that makes dislike UFCS. I can see why
yo
On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg
wrote:
What about functions not marked with @property?
writeln = "asd";
Doesn't look very nice.
struct FileNotFound {
int payload; FileNotFound opBinary(string op :
"+")(FileNotFound rhs) {
return this.payload * rhs.payload;
On 2013-01-23 21:46, Jonathan M Davis wrote:
I confess that it's syntax like that that makes dislike UFCS. I can see why
you might like it, but personally, I find it to be hideous.
But as long as you're not using -property, you can do 2.days to get a Duration
of 2 days, much as I wish that you
On 2013-01-22, 22:28, Jonathan M Davis wrote:
For the most part, static opCall solves the problem.
Add @disable this(); to make sure, though. Otherwise you're likely to
forget
the parentheses somewhere, and have a bug.
--
Simen
On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
> On 2013-01-23 21:46, Jonathan M Davis wrote:
> > I confess that it's syntax like that that makes dislike UFCS. I can see
> > why
> > you might like it, but personally, I find it to be hideous.
> >
> > But as long as you're not using -
On Wed, 2013-01-23 at 15:15 -0500, Andrei Alexandrescu wrote:
[…]
> Given the richness of today's D, I'd say AST macros are not part of the
> mythical plan.
Works for me.
The issue is only whether there is an idiomatic expression for a given
style. For me currently D has everything I need that C
Am 23.01.2013 08:59, schrieb Mehrdad:
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
But the trend is C is becoming more and more a high-level assembler.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
This blog post (the first in a series of three) t
On 1/23/2013 12:02 PM, Jacob Carlborg wrote:
On 2013-01-23 18:09, Timon Gehr wrote:
That still requires at least one of two secondary parsers.
Technically yes, but there's already a demangler available in Phobos/druntime.
Yup. The "pretty" attribute is completely redundant.
On Wednesday, 23 January 2013 at 20:02:36 UTC, Jacob Carlborg
wrote:
On 2013-01-23 18:09, Timon Gehr wrote:
That still requires at least one of two secondary parsers.
Technically yes, but there's already a demangler available in
Phobos/druntime.
Not every program using the json output will
On 1/23/13 3:29 PM, Jacob Carlborg wrote:
On 2013-01-23 08:57, Andrei Alexandrescu wrote:
I completely disagree. (Sorry to foul you twice.) All AST macro systems
I've studied are considerably difficult to understand and use
effectively. By comparison, string macros are brutal and unstructured
b
On 01/23/2013 10:08 PM, Jonathan M Davis wrote:
On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
On 2013-01-23 21:46, Jonathan M Davis wrote:
I confess that it's syntax like that that makes dislike UFCS. I can see
why
you might like it, but personally, I find it to be hideous.
But
OK. I'm going to try to shift the object of this discussion.
Let's forget style for a little (I loves me both the functional
notation, but am also a syntax Nazi).
Clearly, not everyone agrees with what constitutes a property,
and what doesn't. Because of this, there is a strong urge to make
p
My two cents on properties (comments along the way):
alias int delegate() C;
C c;
auto noprop() {return c;}
void noprop(C v) {c = v;}
@property auto prop() {return c;}
@property void prop(C v) {c = v;}
static assert(
is(typeof( noprop ) == function) /* well ... I
guess, technical
On 01/23/2013 10:59 PM, monarch_dodra wrote:
...
IMO: We should be able to keep the optional parenthesis for all
functions (except maybe those that return delegates). Things that are
marked as property, however, MUST respect two things:
1) properties should *NEVER* have parentheses.
2) y
On Wednesday, 23 January 2013 at 20:03:03 UTC, Walter Bright
wrote:
On 1/23/2013 8:06 AM, Jacob Carlborg wrote:
On 2013-01-23 08:50, Walter Bright wrote:
If your program has undefined behavior in it, the -O flag can
definitely
cause that behavior to change.
Yes, I guess that is to be expect
On Wednesday, 23 January 2013 at 22:07:30 UTC, Timon Gehr wrote:
IIRC Adam likes to have both fun = value and fun(value)
available for the same function.
Yeah, it is sometimes useful for methods that can be both chained
and assigned:
foo.bar(10).baz("hello");
vs
foo.bar = 10;
foo.baz = "he
On 01/23/2013 09:33 PM, Jacob Carlborg wrote:
This is how it should look like. Date ranges in Ruby on Rails can be
really beautiful:
date = 2.days.ago
I think we should have the same in D.
As long as your not using -property:
http://dpaste.dzfl.pl/56960911
--
Mike Wey
On Wed, 23 Jan 2013 21:48:32 +0100
"Adam D. Ruppe" wrote:
> On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg
> wrote:
> > What about functions not marked with @property?
> >
> > writeln = "asd";
> >
> > Doesn't look very nice.
>
> struct FileNotFound {
> int payload; FileNotFo
On Wed, 23 Jan 2013 15:11:35 -0500
Andrei Alexandrescu wrote:
> On 1/23/13 1:18 PM, Johannes Pfau wrote:
> > Please do not forget the main reason for @property: Returning a
> > delegate from a function can become ambiguous without it:
> >
> > int a(){return 42;}
> > void b() {return&a;}
> >
> > a
I saw an old thread from 2004 while doing a google search that
discussed D and scientific computing and was looking for some
more recent information or opinions from people who have used it
for such purposes.
I am a graduate student and my thesis work is in numerical
modeling. While I have so
On Wed, 23 Jan 2013 15:14:21 -0500
Andrei Alexandrescu wrote:
> On 1/23/13 1:48 PM, Nick Sabalausky wrote:
> > Having the *caller* decide whether something is a property or not
> > makes as much sense as having the caller decide the function's name,
> > signature and semantics.
>
> No. The calle
On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky
wrote:
that provides absolutely no useful value whatsoever.
Do you think so many of us would be arguing for it and using it
if it was of no value whatsoever?
Note that properties are *not* functions
Indeed, which is why I sepa
On Wed, 23 Jan 2013 21:29:14 +0100
Andrej Mitrovic wrote:
> On 1/23/13, Adam D. Ruppe wrote:
> > On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
> > Amen! -property MUST die. @property should fix the real problems
> > with properties, not leave that broken while adding new probl
On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
I saw an old thread from 2004 while doing a google search that
discussed D and scientific computing and was looking for some
more recent information or opinions from people who have used
it for such purposes.
I am a graduate student a
On Wednesday, 23 January 2013 at 20:29:24 UTC, Andrej Mitrovic
wrote:
This is regardless of the -property switch. I would expect the
second call to work.
Indeed. I don't know if it is filed (I think I saw it mentioned
on irc yesterday though, so it might be), but this is exactly why
-property
On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
I saw an old thread from 2004 while doing a google search that
discussed D and scientific computing and was looking for some
more recent information or opinions from people who have used
it for such purposes.
I am a graduate student a
On Wed, 23 Jan 2013 21:33:07 +0100
Jacob Carlborg wrote:
>
> This is how it should look like. Date ranges in Ruby on Rails can be
> really beautiful:
>
> date = 2.days.ago
>
Honestly, I really don't like that. It trades clear semantics for a
bunch of magic to achieve the dubious goal of makin
On Wednesday, 23 January 2013 at 22:07:20 UTC, anonymous wrote:
alias int delegate() C;
C c;
auto noprop() {return c;}
void noprop(C v) {c = v;}
@property auto prop() {return c;}
@property void prop(C v) {c = v;}
&& is(typeof( {return noprop;}() ) == C) /* fails with
-property. that's goofy */
On Wed, 23 Jan 2013 21:54:54 +0100
Jacob Carlborg wrote:
> On 2013-01-23 21:46, Jonathan M Davis wrote:
>
> > I confess that it's syntax like that that makes dislike UFCS. I can
> > see why you might like it, but personally, I find it to be hideous.
> >
> > But as long as you're not using -prope
On 01/23/2013 11:40 PM, Nick Sabalausky wrote:
On Wed, 23 Jan 2013 15:14:21 -0500
Andrei Alexandrescu wrote:
On 1/23/13 1:48 PM, Nick Sabalausky wrote:
Having the *caller* decide whether something is a property or not
makes as much sense as having the caller decide the function's name,
signat
On 1/23/13 5:32 PM, Nick Sabalausky wrote:
I'd rather not see more "Sometimes the language lets me skip , and
sometimes it complains" get introduced into the language. That
complicates the language and makes the language harder to understand.
There are cases where that strategy has certainly
On 1/23/13 5:46 PM, Adam D. Ruppe wrote:
On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky wrote:
that provides absolutely no useful value whatsoever.
Do you think so many of us would be arguing for it and using it if it
was of no value whatsoever?
Note that properties are *not*
On 1/23/13 5:40 PM, Nick Sabalausky wrote:
On Wed, 23 Jan 2013 15:14:21 -0500
Andrei Alexandrescu wrote:
On 1/23/13 1:48 PM, Nick Sabalausky wrote:
Having the *caller* decide whether something is a property or not
makes as much sense as having the caller decide the function's name,
signature
1 - 100 of 138 matches
Mail list logo
