thesis, so removing an "@property" attribute
is potentially breaking. The opposite though is not so true. You
can add @property to anything, and never break code.
...
So I thought I'd discuss: Would there be a reason to not make dur
a property? This should impact no-one, but mak
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 chan
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 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'
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 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
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 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 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 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
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 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 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
On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
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 lea
On Wednesday, January 23, 2013 18:35:24 Andrei Alexandrescu wrote:
> UFCS has effectively buried the case for requiring parens.
Honestly, I'd love to require parens even with UFCS, but I think that it's
clear that most folks want the parens to be optional for UFCS, and at this
point, requiring p
On Wed, 23 Jan 2013 18:39:49 -0500
Andrei Alexandrescu wrote:
>
> We need a good DIP on this. UFCS has destroyed all arguments in favor
> of requiring parens.
Uhh, how exactly?
On Thu, 24 Jan 2013 00:30:43 +0100
Timon Gehr wrote:
> 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
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. [snip]
DIPs are good in theory but I think the process really needs to
be formalized. In the past 3 years there have been thirteen DIPs
with only one being approved and implemented. Perhaps
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu wrote:
> 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
Nick Sabalausky:
This is a problem that other languages have *already* solved,
with
well-known, well-understood solutions (ie: the "action==paren,
data==no parem" rule). Unfortunately, despite the readily
available
solution, D is still trying to wrap its head around the matter,
and
winds up f
On Thu, 24 Jan 2013 00:45:02 +0100
Timon Gehr wrote:
> On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
> > 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! -p
On Wed, 23 Jan 2013 22:53:45 +0100
Timon Gehr wrote:
>
> Likewise, there is no problem with 2.days.ago.
>
> Clock.currTime() - dur!"days"(2) is more verbose without being more
> clear.
*IMO*: The problem with that latter example is just (what I see as) some
unfortunate choices for naming and su
On Wed, 23 Jan 2013 22:59:38 +0100
"monarch_dodra" wrote:
>
>
> IMO: We should be able to keep the optional parenthesis for all
> functions (except maybe those that return delegates).
I'm not a fan of that as I think the need for special-casing of
functions returning delegates is not w
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments in
favor of requiring parens. There is no question we must do
this. Anyone inclined toward writing a detailed DIP?
Andrei
What about optional parens on non
On Thursday, 24 January 2013 at 04:00:44 UTC, Nick Sabalausky
wrote:
On Wed, 23 Jan 2013 22:59:38 +0100
"monarch_dodra" wrote:
IMO: We should be able to keep the optional parenthesis for
all functions (except maybe those that return delegates).
I'm not a fan of that as I think the
On 1/23/13 8:59 PM, Nick Sabalausky wrote:
On Wed, 23 Jan 2013 18:39:49 -0500
Andrei Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments in favor
of requiring parens.
Uhh, how exactly?
With compelling examples that look awesome without parens and look awful
wi
On 1/24/13 1:18 AM, monarch_dodra wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments in favor
of requiring parens. There is no question we must do this. Anyone
inclined toward writing a detailed DIP?
And
On 1/23/13 10:02 PM, Nick Sabalausky wrote:
First of all, spacing helps:
a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()
So does not trying to cram everything into a one-liner:
auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
a.map!descriptiveName().days().ago().writeln()
On Thursday, January 24, 2013 07:20:22 monarch_dodra wrote:
> The irony here though is that "-property" enforces the opposite
>
> :/ (non-properties always have parens...)
-property is thoroughly broken. It was supposed to do strong property
enforcement (never parens with properties and always p
On Thursday, January 24, 2013 01:33:29 Andrei Alexandrescu wrote:
> If you find this not wanting and not improvable we might have reached an
> irreducible position.
I think that it's been clear for some time that there's no way to please both
the folks who want strong property enforcement and tho
On 2013-01-24 03:17, Brad Anderson wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
We need a good DIP on this. [snip]
DIPs are good in theory but I think the process really needs to be
formalized. In the past 3 years there have been thirteen DIPs with only
one
On 2013-01-24 03:02, Nick Sabalausky wrote:
foo.bar() // Perform action
foo.bar // Access data
Who says it has to be like this.
--
/Jacob Carlborg
I've always secretly hated the ambiguity in D's syntax. E.g:
foo.bar
What could foo and bar be? D has many more answers than C++:
D C++
foo bar foo bar
Module/Namespacex x
Typex x
Variablex x x x
On 2013-01-23 22:59, monarch_dodra wrote:
In this context, what does it mean then to have something be "a property" ?
I think we should remember what "@property" (as I understood it) is
meant for: a function that can emulate being a object. The de-facto
example being "front".
It's for a metho
On 2013-01-24 00:16, Nick Sabalausky wrote:
I'll certainly grant that, insofar as the written order is backwards
from the execution order. I think the "ago" is that part that bugs me
the most. It's too clever. I could live with "2.days", but I'd prefer
"days(2)" since that looks like a type cons
On 2013-01-24 00:07, Nick Sabalausky wrote:
Honestly, I really don't like that. It trades clear semantics for a
bunch of magic to achieve the dubious goal of making code look more
like English (a notably high-ambiguity language). If I valued languages
imitating English, I'd be doing everything i
On Thursday, 24 January 2013 at 08:41:34 UTC, Jacob Carlborg
wrote:
On 2013-01-23 22:59, monarch_dodra wrote:
In this context, what does it mean then to have something be
"a property" ?
I think we should remember what "@property" (as I understood
it) is
meant for: a function that can emulate
On Thursday, 24 January 2013 at 06:34:58 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 1:18 AM, monarch_dodra wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments
in favor
of requiring parens. There is no qu
On Thu, 24 Jan 2013 09:52:38 +0100
Jacob Carlborg wrote:
> On 2013-01-24 00:16, Nick Sabalausky wrote:
>
> > I'll certainly grant that, insofar as the written order is backwards
> > from the execution order. I think the "ago" is that part that bugs
> > me the most. It's too clever. I could live
On 01/24/2013 04:02 AM, Nick Sabalausky wrote:
On Thu, 24 Jan 2013 00:45:02 +0100
Timon Gehr wrote:
On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
On Wed, 23 Jan 2013 21:29:14 +0100
...
Don't know if it's filed, but yea: Optional empty-parens and
the practice of conflating properties with fun
On 01/24/2013 10:52 AM, Nick Sabalausky wrote:
now - blah vs. now + blah
Now we have caught you.
On 2013-01-24 10:11, monarch_dodra wrote:
IMO, it not currently doing so is a limitation
Yes, that's what I'm saying. You cannot swap properties and fields willy
nilly using the current implementation.
--
/Jacob Carlborg
On 2013-00-24 05:01, Nick Sabalausky
wrote:
On Wed, 23 Jan 2013 22:59:38 +0100
"monarch_dodra" wrote:
IMO: We should be able to keep the optional parenthesis for all
functions (except maybe those that return delegates).
I'm not a fan of that as I think the need for special-casin
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments in
favor of requiring parens. There is no question we must do
this. Anyone inclined toward writing a detailed DIP?
Let me strongly disagree. Language feature
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments
in favor of requiring parens. There is no question we must do
this. Anyone inclined toward writin
On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments
in favor of requiring parens. Th
On Thursday, 24 January 2013 at 15:02:02 UTC, deadalnix wrote:
On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei
Alexandrescu wrote:
We need a good DIP on this. UF
Am Thu, 24 Jan 2013 09:20:44 +0100
schrieb Jacob Carlborg :
> On 2013-01-24 03:02, Nick Sabalausky wrote:
>
> > foo.bar() // Perform action
> > foo.bar // Access data
>
> Who says it has to be like this.
>
.NET guidelines since .NET 1.1 for example:
"In general, methods represent actions an
On Thursday, 24 January 2013 at 15:32:36 UTC, Maxim Fomin wrote:
Perhaps a bad example but I disagree that any feature that can
be implemented as a library, should not be introduced as a
language feature. Some features needed to be embedded into
language because as a library features they would
On 1/24/13 3:20 AM, Jacob Carlborg wrote:
On 2013-01-24 03:02, Nick Sabalausky wrote:
foo.bar() // Perform action
foo.bar // Access data
Who says it has to be like this.
Agreed. It's an implied, unstated assumption - the most dangerous kind.
Andrei
On 1/24/13 3:38 AM, Tommi wrote:
I've always secretly hated the ambiguity in D's syntax. E.g:
foo.bar
What could foo and bar be? D has many more answers than C++:
D C++
foo bar foo bar
Module/Namespace x x
Type x x
Variable x x x x
Method x
Free function x x
Nah, C++ has also namespace, inne
On 1/24/13 4:28 AM, monarch_dodra wrote:
We actually have one, which I think I agree with:
http://wiki.dlang.org/DIP21
Walter convinced me last night that eliminating @property is more sensible.
Andrei
On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 3:38 AM, Tommi wrote:
I've always secretly hated the ambiguity in D's syntax. E.g:
foo.bar
What could foo and bar be? D has many more answers than C++:
D C++
foo bar foo bar
Module/Namespace x x
Type x x
Varia
On Thursday, 24 January 2013 at 16:30:45 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 4:28 AM, monarch_dodra wrote:
We actually have one, which I think I agree with:
http://wiki.dlang.org/DIP21
Walter convinced me last night that eliminating @property is
more sensible.
He hasn't even *tried*
On 1/24/13 9:25 AM, deadalnix wrote:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
We need a good DIP on this. UFCS has destroyed all arguments in favor
of requiring parens. There is no question we must do this. Anyone
inclined toward writing a detailed DIP?
Let me
On 1/24/13 11:32 AM, deadalnix wrote:
On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:
On 1/24/13 3:38 AM, Tommi wrote:
I've always secretly hated the ambiguity in D's syntax. E.g:
foo.bar
What could foo and bar be? D has many more answers than C++:
D C++
foo bar foo
On Thu, 24 Jan 2013 11:25:38 -0500
Andrei Alexandrescu wrote:
> On 1/24/13 3:20 AM, Jacob Carlborg wrote:
> > On 2013-01-24 03:02, Nick Sabalausky wrote:
> >
> >> foo.bar() // Perform action
> >> foo.bar // Access data
> >
> > Who says it has to be like this.
>
> Agreed. It's an implied, unstate
On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
> On 1/24/13 4:28 AM, monarch_dodra wrote:
> > We actually have one, which I think I agree with:
> > http://wiki.dlang.org/DIP21
>
> Walter convinced me last night that eliminating @property is more sensible.
Well, that's bad news.
Am Thu, 24 Jan 2013 20:26:25 +0100
schrieb "Jonathan M Davis" :
> On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
> > On 1/24/13 4:28 AM, monarch_dodra wrote:
> > > We actually have one, which I think I agree with:
> > > http://wiki.dlang.org/DIP21
> >
> > Walter convinced me la
24-Jan-2013 06:46, Nick Sabalausky пишет:
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu wrote:
The real question is "Is this an action or data?" (And obviously I mean
when viewed from outside the encapsulation, I don't mean the
implementation.) Note that the answer to that question i
1 - 100 of 125 matches
Mail list logo
