On Monday, 19 November 2012 at 06:53:46 UTC, Andrei Alexandrescu
wrote:
On 11/19/12 1:16 AM, Jonathan M Davis wrote:
On Monday, November 19, 2012 07:02:03 Rob T wrote:
I think UFCS changes the playfield quite a lot. Code using UFCS
looks a whole lot crappier with a bunch of arbitrary extra
par
I think having some kind of pipe operator would be a better
solution. But it's probably too late to add any of those now.
I'm sorry, I didn't realize I was replying to a two months old
post.
[1] If you think the required '()' in UFCS chains look ugly,
you're right, but the
right fix isn't to butcher the language. '()' carry important
information. Having
a mode where function calls are made w/o the parens would be a
good idea, but it
should be limited to an explicit scope. ie someth
On Monday, 28 January 2013 at 19:55:48 UTC, Jacob Carlborg wrote:
On 2013-01-28 15:00, Maxim Fomin wrote:
Returning void instead of int in the example break assignment
chaining a
= b = c. Besides, how such implicitly defined functions may
call user
defined code (check input validity, call eve
On Mon, 28 Jan 2013 15:00:41 -0500, Jacob Carlborg wrote:
On 2013-01-28 17:21, Steven Schveighoffer wrote:
But I think it would be wasteful in the given case. __a is already in
the register, I think actually the return __a is a noop.
In other cases, where the property value may be a large
On Mon, 28 Jan 2013 15:00:41 -0500, Jacob Carlborg wrote:
On 2013-01-28 17:21, Steven Schveighoffer wrote:
But I think it would be wasteful in the given case. __a is already in
the register, I think actually the return __a is a noop.
In other cases, where the property value may be a large
On 2013-01-28 17:21, Steven Schveighoffer wrote:
I think Jacob's point is that a = b = c would lower to:
b = c;
a = b;
This is how the semantics should be. This also shows a clear complete
example:
http://forum.dlang.org/thread/uxhgbxdsselokcdkv...@forum.dlang.org?page=14#post-ke6l44:242mf
On 2013-01-28 15:00, Maxim Fomin wrote:
Returning void instead of int in the example break assignment chaining a
= b = c. Besides, how such implicitly defined functions may call user
defined code (check input validity, call events, etc.)?
No, the compiler should do a rewrite, as follows:
clas
On Monday, 28 January 2013 at 17:41:07 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 17:20:13 UTC, Maxim Fomin wrote:
...
Those are C rules, do not forget it. Thus value of (b = c) IS
equivalent to value of b when lvalues are considered. And you
are perfectly allowed to forget about c an
On Monday, January 28, 2013 13:31:34 Jacob Carlborg wrote:
> > Having the compiler lower the following:
> >
> > @property int a;
> >
> > to
> >
> > private int __a;
> >
> > @property int a() {
> > return __a;
> > }
> > @property int a(int new_a) {
> >
> > __a=new_a;
> > return __a;
> >
> > }
On Monday, 28 January 2013 at 03:24:09 UTC, Steven Schveighoffer
wrote:
There are three intentions when creating a function w/ regards
to properties:
1. You intend the function to be called without parentheses to
clarify it is a property.
2. You intend the function to be only called with paren
On Monday, 28 January 2013 at 17:20:13 UTC, Maxim Fomin wrote:
...
Those are C rules, do not forget it. Thus value of (b = c) IS
equivalent to value of b when lvalues are considered. And you are
perfectly allowed to forget about c and do a = b after b = c was
evaluated. It is plain old data,
On Monday, 28 January 2013 at 16:55:40 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 16:50:37 UTC, Maxim Fomin wrote:
Than value of this expression (note, that evaluated expression
is not b, it is b = c) is assigned to a.
Quoting you (that was exactly part of standard I was referring
too)
On Monday, 28 January 2013 at 16:55:40 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 16:50:37 UTC, Maxim Fomin wrote:
Than value of this expression (note, that evaluated expression
is not b, it is b = c) is assigned to a.
Quoting you (that was exactly part of standard I was referring
too)
On Monday, 28 January 2013 at 16:50:37 UTC, Maxim Fomin wrote:
Than value of this expression (note, that evaluated expression
is not b, it is b = c) is assigned to a.
Quoting you (that was exactly part of standard I was referring
too):
"assignment expression has the value of the left operand"
On Monday, 28 January 2013 at 15:31:48 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 15:05:21 UTC, Maxim Fomin wrote:
It should be rewritten to a.setter(b.setter(c.getter()))
That is exactly the problem. "a = b = c" should be rewritten as:
b.set(c.get());
a.set(b.get()); // or a.set(c.get()
On Mon, 28 Jan 2013 09:00:15 -0500, Maxim Fomin
wrote:
On Monday, 28 January 2013 at 12:31:35 UTC, Jacob Carlborg wrote:
On 2013-01-28 12:44, Robert wrote:
Having the compiler lower the following:
@property int a;
to
private int __a;
@property int a() {
return __a;
}
@property int a(int
They don't. If you want such behaviour, you would write your own setter
getter, with @property attribute, just like you do now.
Best regards,
Robert
On Mon, 2013-01-28 at 15:00 +0100, Maxim Fomin wrote:
> Besides, how such implicitly defined
> functions may call user defined code (check input v
On Monday, 28 January 2013 at 15:05:21 UTC, Maxim Fomin wrote:
It should be rewritten to a.setter(b.setter(c.getter()))
That is exactly the problem. "a = b = c" should be rewritten as:
b.set(c.get());
a.set(b.get()); // or a.set(c.get()); do not remember C rules
On Monday, 28 January 2013 at 15:05:21 UTC, Maxim Fomin wrote:
On Monday, 28 January 2013 at 14:38:19 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:28:30 UTC, Maxim Fomin wrote:
On Monday, 28 January 2013 at 14:09:20 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim F
On Monday, 28 January 2013 at 14:38:19 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:28:30 UTC, Maxim Fomin wrote:
On Monday, 28 January 2013 at 14:09:20 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim Fomin wrote:
Returning void instead of int in the example break
On Monday, 28 January 2013 at 14:44:15 UTC, deadalnix wrote:
It is not that obvious, as the result of a = b is also equal to
b.
AFAIR it was defined strictly in C standard to be one two. Do not
remember which one and do not have my trustful standard pdf
nearby.
On Monday, 28 January 2013 at 14:38:19 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:28:30 UTC, Maxim Fomin wrote:
On Monday, 28 January 2013 at 14:09:20 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim Fomin wrote:
Returning void instead of int in the example break
On Monday, 28 January 2013 at 14:28:30 UTC, Maxim Fomin wrote:
On Monday, 28 January 2013 at 14:09:20 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim Fomin wrote:
Returning void instead of int in the example break assignment
chaining a = b = c. Besides, how such implicitly
On Monday, 28 January 2013 at 14:09:20 UTC, Dicebot wrote:
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim Fomin wrote:
Returning void instead of int in the example break assignment
chaining a = b = c. Besides, how such implicitly defined
functions may call user defined code (check input vali
On Monday, 28 January 2013 at 14:00:16 UTC, Maxim Fomin wrote:
Returning void instead of int in the example break assignment
chaining a = b = c. Besides, how such implicitly defined
functions may call user defined code (check input validity,
call events, etc.)?
It should not if evaluating the
On Monday, 28 January 2013 at 12:31:35 UTC, Jacob Carlborg wrote:
On 2013-01-28 12:44, Robert wrote:
@property use:
I'd like to point out, that regardless of the "with
parens/without
parens" stuff, marking properties with @property makes sense.
So that
tools and frameworks can recognize them
On 2013-01-28 12:44, Robert wrote:
@property use:
I'd like to point out, that regardless of the "with parens/without
parens" stuff, marking properties with @property makes sense. So that
tools and frameworks can recognize them as such.
I completely agree. I have created a struct called "attrib
@property use:
I'd like to point out, that regardless of the "with parens/without
parens" stuff, marking properties with @property makes sense. So that
tools and frameworks can recognize them as such. This also implies that
fields that are meant as properties should be declared @property and the
c
On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis
wrote:
I'd _love_ to make it illegal to call non-property functions without
parens,
and there are definitely folks around here who agree with me, including
some on
the Phobos dev team (e.g. Steven has always agreed with me when this has
On 12/03/12 03:23, kenji hara wrote:
> I had been trying to advance the phase to the next.
> Now, an experimental pull request is here.
> https://github.com/D-Programming-Language/dmd/pull/1311
>
>
> This change can distinguish almost usages between property and non-property
> syntax
>
> i
On Wednesday, 5 December 2012 at 20:27:18 UTC, Rob T wrote:
On Wednesday, 5 December 2012 at 18:32:16 UTC, deadalnix wrote:
I think the argument for vs against is simply a coding style
issue, some like dropping empty braces, some do not.
--rt
It is also a ambiguity issue
The () acts like a
On Wednesday, 5 December 2012 at 18:32:16 UTC, deadalnix wrote:
I think the argument for vs against is simply a coding style
issue, some like dropping empty braces, some do not.
--rt
It is also a ambiguity issue
The () acts like a naming convention, and with or without
enforcement you are
On Tuesday, 4 December 2012 at 18:28:55 UTC, Rob T wrote:
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't
On Wed, 05 Dec 2012 16:49:22 -, Rob T wrote:
On Tuesday, 4 December 2012 at 21:58:49 UTC, Regan Heath wrote:
Exact costs, yes. But syntactic properties can, and have historically
also given a good indication of costs and this is useful. Removing
that, is less than useful and potential
On Tuesday, 4 December 2012 at 21:58:49 UTC, Regan Heath wrote:
Exact costs, yes. But syntactic properties can, and have
historically also given a good indication of costs and this is
useful. Removing that, is less than useful and potentially
surprising.
Compare that to what you gain from t
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
+1
5.writeln is go
On Mon, 03 Dec 2012 04:02:15 -, Timon Gehr wrote:
On 12/02/2012 09:19 PM, Regan Heath wrote:
On Sun, 02 Dec 2012 18:47:26 -, Rob T wrote:
If someone can honestly demonstrate a non-subjective reason why there
must be a difference between function call and variable assignments,
please
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
That's exactly what Nimrod does ;-). It also allows to leave out
the () for calls used as a statement (not as an expression).
BTW Nimrod calls it "method call syntax"
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing calling a property
function with no arguments.
It's regular function called as property [getter] of module.
It's nice to have @property like in C
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing calling a property
function with no arguments.
It's regular function called as property [getter] of module.
It's nice to have @property like in C
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
This is exactly what Nimrod does. ;-) The () can also be omitted
in calls used as a statement (not as an expression).
BTW Nimrod calls it "method call syntax"; there
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On 04/12/2012 16:24, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing callin
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
int func() { return 1; }
void func(int n) { }
@property int prop() { return 2; }
@property void prop(int n) { }
void main() {
// Without -property switch, all lines can compile.
// With -property switch:
func(); // OK -> OK
func(1);// OK -> OK
func; // OK -> OK [*]
func
On 12/03/12 05:10, Timon Gehr wrote:
> On 12/02/2012 12:36 PM, Artur Skawina wrote:
>> On 12/02/12 07:57, Jonathan M Davis wrote:
>>> On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
And what do you think about map!(x => x * x) = generator(x, y, z)
?
>>>
>>> What's that even suppose
On 12/02/2012 12:36 PM, Artur Skawina wrote:
On 12/02/12 07:57, Jonathan M Davis wrote:
On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
And what do you think about map!(x => x * x) = generator(x, y, z)
?
What's that even supposed to mean? map has been given no function argument
either
On 12/02/2012 09:19 PM, Regan Heath wrote:
On Sun, 02 Dec 2012 18:47:26 -, Rob T wrote:
If someone can honestly demonstrate a non-subjective reason why there
must be a difference between function call and variable assignments,
please show it. So far I've only seen arguments that boil down t
On 12/2/12 1:49 AM, deadalnix wrote:
On Tuesday, 20 November 2012 at 04:12:54 UTC, Andrei Alexandrescu wrote:
On 11/19/12 5:23 PM, Rob T wrote:
I don't have an answer, but there may be more to the picture than we
think.
I agree. In particular I find it a specious argument to insist on
religio
I had been trying to advance the phase to the next.
Now, an experimental pull request is here.
https://github.com/D-Programming-Language/dmd/pull/1311
This change can distinguish almost usages between property and non-property
syntax
int func() { return 1; }
void func(int n) { }
@property in
On 12/02/12 19:48, Rob T wrote:
> There's more than just @property that operate like variables.
>
> Should we restrict this as well?
>
> struct stdio
> {
> void opAssign(T)( T a_arg )
> {
>writeln( a_arg );
> }
> }
>
> main()
> {
> stdio writeln;
> writeln = "hellow w
On Sun, 02 Dec 2012 18:47:26 -, Rob T wrote:
If someone can honestly demonstrate a non-subjective reason why there
must be a difference between function call and variable assignments,
please show it. So far I've only seen arguments that boil down to "I
don't like it".
A variable assig
There's more than just @property that operate like variables.
Should we restrict this as well?
struct stdio
{
void opAssign(T)( T a_arg )
{
writeln( a_arg );
}
}
main()
{
stdio writeln;
writeln = "hellow world";
}
Conceptually, I don't see why we have to impose a differenc
There's more than just @property that operate like variables.
Should we restrict this as well?
struct stdio
{
void opAssign(T)( T a_arg )
{
writeln( a_arg );
}
}
main()
{
stdio writeln;
writeln = "hellow world";
}
Conceptually, I don't see why we have to impose a dif
On Sunday, December 02, 2012 12:36:53 Artur Skawina wrote:
> [1] If you think the required '()' in UFCS chains look ugly, you're right,
> but the right fix isn't to butcher the language.
I agree, but those who think that seem to be outnumbered by those who don't
want to have to use the parens - p
On 12/2/12, deadalnix wrote:
> BTW, I can't edit in the wiki? When I try to do so, it says me
> that deadalnix is an invalid username. If I need to register, I
> didn't found out how.
It requires a silly CamelCase style username. You can try and edit the
new wiki though: http://dwiki.kimsufi.thec
On 12/02/12 07:57, Jonathan M Davis wrote:
> On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
>> And what do you think about map!(x => x * x) = generator(x, y, z)
>> ?
>
> What's that even supposed to mean? map has been given no function argument
> either as UFCS or with a normal function c
On Sunday, 2 December 2012 at 06:58:12 UTC, Jonathan M Davis
wrote:
On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
And what do you think about map!(x => x * x) = generator(x, y,
z)
?
What's that even supposed to mean? map has been given no
function argument
either as UFCS or with a n
On Sunday, 2 December 2012 at 01:04:03 UTC, Jonathan M Davis
wrote:
On Sunday, December 02, 2012 01:16:40 Andrej Mitrovic wrote:
On 11/20/12, Jonathan M Davis wrote:
> I suspect that the
> best that we can hope for at this point is for lax property
> enforcement -
> that is that it's enforced
On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
> And what do you think about map!(x => x * x) = generator(x, y, z)
> ?
What's that even supposed to mean? map has been given no function argument
either as UFCS or with a normal function call, so it's not being called. And
even if it were,
On Tuesday, 20 November 2012 at 04:12:54 UTC, Andrei Alexandrescu
wrote:
On 11/19/12 5:23 PM, Rob T wrote:
I don't have an answer, but there may be more to the picture
than we think.
I agree. In particular I find it a specious argument to insist
on religiously associating "()" with function c
On Sunday, December 02, 2012 01:16:40 Andrej Mitrovic wrote:
> On 11/20/12, Jonathan M Davis wrote:
> > I suspect that the
> > best that we can hope for at this point is for lax property enforcement -
> > that is that it's enforced that @property functions are used as properties
> > but there is n
On Wednesday, 21 November 2012 at 18:07:42 UTC, Jacob Carlborg
wrote:
On 2012-11-21 18:53, deadalnix wrote:
I don't understand why dropping () is that a big deal when
dropping &
isn't.
Now I'm really confused. What did you mean when you original
wrote:
"Note the map(reverse) and not map(&
On 2012-11-21 18:53, deadalnix wrote:
I don't understand why dropping () is that a big deal when dropping &
isn't.
Now I'm really confused. What did you mean when you original wrote:
"Note the map(reverse) and not map(&reverse)"
--
/Jacob Carlborg
On 11/21/2012 06:53 PM, deadalnix wrote:
On Wednesday, 21 November 2012 at 07:44:36 UTC, Jacob Carlborg wrote:
On 2012-11-21 07:55, deadalnix wrote:
Note the map(reverse) and not map(&reverse)
I said "fairly similar" not "exactly the same" :)
I don't understand why dropping () is that a bi
On Wednesday, 21 November 2012 at 07:44:36 UTC, Jacob Carlborg
wrote:
On 2012-11-21 07:55, deadalnix wrote:
Note the map(reverse) and not map(&reverse)
I said "fairly similar" not "exactly the same" :)
I don't understand why dropping () is that a big deal when
dropping & isn't.
On Wed, 21 Nov 2012 06:07:51 -, deadalnix wrote:
Le 20/11/2012 12:18, Timon Gehr a écrit :
On 11/20/2012 02:49 PM, Regan Heath wrote:
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for
On 2012-11-21 07:55, deadalnix wrote:
Note the map(reverse) and not map(&reverse)
I said "fairly similar" not "exactly the same" :)
--
/Jacob Carlborg
Le 20/11/2012 04:33, Jacob Carlborg a écrit :
On 2012-11-20 08:48, thedeemon wrote:
This is just an old habit to see identifier with parens as a function
call and identifier without parens as a variable, so calling functions
without parens seem too unconventional to you. However there are many
Le 20/11/2012 12:18, Timon Gehr a écrit :
On 11/20/2012 02:49 PM, Regan Heath wrote:
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
On Tuesday, 20 November 2012 at 21:19:20 UTC, Timon Gehr wrote:
On 11/20/2012 09:56 PM, deadalnix wrote:
On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
I'm not sure how it fit in the DIP but &funName is ambiguous
On Tuesday, 20 November 2012 at 19:12:58 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
wrote:
Given the fact that this subject is extremely devisive, I
suspect that the
best that we can hope for at this point is for lax property
enforcement
@property
On 11/20/2012 09:56 PM, deadalnix wrote:
On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
I'm not sure how it fit in the DIP but &funName is ambiguous when
funName return a reference.
We can just define this away
On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
I'm not sure how it fit in the DIP but &funName is ambiguous
when funName return a reference.
We can just define this away: &funName if it isn't a @property
is the
On 11/20/2012 02:49 PM, Regan Heath wrote:
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
Yes. We should *only* be changing the way
On Tuesday, November 20, 2012 20:12:56 Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
>
> wrote:
> > Given the fact that this subject is extremely devisive, I
> > suspect that the
> > best that we can hope for at this point is for lax property
> > enforcement
On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
wrote:
Given the fact that this subject is extremely devisive, I
suspect that the
best that we can hope for at this point is for lax property
enforcement
@property shouldn't be about enforcement. This is the fundamental
flaw in th
On Tuesday, November 20, 2012 19:48:01 monarch_dodra wrote:
> On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
> > Here's another way to test if the idea is sound, by asking a
>
> > few questions:
> After thinking about it a bit more, I think there may be two
> conflicting notions:
>
>
On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
Here's another way to test if the idea is sound, by asking a
few questions:
After thinking about it a bit more, I think there may be two
conflicting notions:
a) The use of optional parenthesis.
b) The @property switch, which allows a
Just a quick thought... it's not like a = 10 has no way to
trigger a function anyway.
opAssign does it. Is that evil? This discussion kinda reminds me
of some of the C++ arguments over operator overloading. They
argue overloaded operators are evil because they don't look like
function calls..
On Tuesday, 20 November 2012 at 13:26:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg
wrote:
Should this be allowed for functions that isn't marked with
@property:
foo = 3;
Yes. We should *only* be changing the way @property is
implemented. (Namely,
On Tuesday, 20 November 2012 at 14:13:51 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
Usually I'd agree but this is a case of a wart we should just
remove IMO. The fix for breaking cases is simple, add
@property.
meh, I sometimes use it, but if o
BTW I've been pasting some of my posts into the wiki thing
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21#section4
Kinda sloppy to just paste, but this way everything on my mind is
in one place so we don't have to reread the thread to get it
together.
Of course, being a wiki, f
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
Usually I'd agree but this is a case of a wart we should just
remove IMO. The fix for breaking cases is simple, add
@property.
meh, I sometimes use it, but if overloading on @property works,
that's easy enough to allow both way
On Tue, 20 Nov 2012 13:20:10 -, monarch_dodra
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
Hell no!
+1 I think this "feature" should just be removed, and @property
impleme
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
Yes. We should *only* be changing the way @property is implemented.
(Namely, actua
On Tuesday, 20 November 2012 at 05:31:09 UTC, deadalnix wrote:
This make it impossible to only define a getter only when one
want to return by reference.
If there isn't a setter, you don't change things.
If setter is present:
foo = foo + 1; // becomes: foo(foo() + 1);
If setter is not present
On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote:
I'm not sure how it fit in the DIP but &funName is ambiguous
when funName return a reference.
We can just define this away: &funName if it isn't a @property is
the address of the function.
If it is a @property, ALL operations wor
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg
wrote:
Should this be allowed for functions that isn't marked with
@property:
foo = 3;
Yes. We should *only* be changing the way @property is
implemented. (Namely, actually implementing it!)
Don't want to break existing code. The
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg
wrote:
Should this be allowed for functions that isn't marked with
@property:
foo = 3;
Hell no!
On 2012-11-19 19:02, Adam D. Ruppe wrote:
On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu wrote:
Would you please start a DIP with a paste of this idea?
here it is:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21
I tried to implement this a while ago and hit s
On 2012-11-20 08:48, thedeemon wrote:
This is just an old habit to see identifier with parens as a function
call and identifier without parens as a variable, so calling functions
without parens seem too unconventional to you. However there are many
languages which dropped this tradition and they
On 11/20/12 2:48 AM, thedeemon wrote:
[snip]
"one two three".split.map{|s| s.reverse}.join(' ')
in Ruby
print . unwords . map reverse . words $ "one two three"
in Haskell
"one two three" |> split " " |> List.map reverse |> String.join " " |>
print_string
in OCaml
and something similar and even
On 2012-11-19 23:23, Rob T wrote:
Also do not forget that we can not only drop the (), but also perform
assignments to functions that take in one variable, but I'm not sure if
the return must be void for that to work. It seems strange to allow
arbitrarily dual function/variable constructs for fu
1 - 100 of 143 matches
Mail list logo
