On 14/12/11 8:59 PM, Steven Schveighoffer wrote:
On Wed, 14 Dec 2011 15:39:55 -0500, Peter Alexander
wrote:
On 14/12/11 8:16 AM, Timon Gehr wrote:
On 12/14/2011 12:35 AM, Peter Alexander wrote:
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/
Steven Schveighoffer:
> I also don't think dup, reverse, or sort should be array properties. But
> these
> are pieces of the language that have been there forever. To change them
> now would be disruptive for very little gain.
sort and reverse properties will be deprecated and later remove
On Wed, 14 Dec 2011 15:39:55 -0500, Peter Alexander
wrote:
On 14/12/11 8:16 AM, Timon Gehr wrote:
On 12/14/2011 12:35 AM, Peter Alexander wrote:
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesd
On 12/14/2011 09:39 PM, Peter Alexander wrote:
On 14/12/11 8:16 AM, Timon Gehr wrote:
On 12/14/2011 12:35 AM, Peter Alexander wrote:
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December
Peter Alexander:
> Well, it is a little. It makes it difficult to scan code looking for GC
> allocations, or even scan code looking for inefficiencies.
>
> Obviously I know now that I have to look for .length assignments on
> arrays, but it can be quite horrific when looking at code that uses
On 14/12/11 8:16 AM, Timon Gehr wrote:
On 12/14/2011 12:35 AM, Peter Alexander wrote:
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
wrote:
On Wed, 14 Dec 2011 13:50:09 -, Michel Fortin
wrote:
On 2011-12-14 13:27:57 +, "Regan Heath" said:
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
wrote:
By "code patterns", you mean something like this?
struct Foo
{
int getBar();
I don't mind @property, usually I just create one property block for a
class, e.g.:
@property
{
// funcs..
}
On Tue, 13 Dec 2011 18:08:43 -0500, Andrei Alexandrescu
wrote:
On 12/13/11 5:14 PM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
wrote:
There's a phrase in Romanian that quite applies: "From the la
On 2011-12-14 13:27:57 +, "Regan Heath" said:
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
wrote:
By "code patterns", you mean something like this?
struct Foo
{
int getBar();
void setBar(int);
}
void main()
{
On Wed, 14 Dec 2011 13:27:57 -, Regan Heath
wrote:
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
wrote:
On 2011-12-13 23:08:43 +, Andrei Alexandrescu
said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (whi
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
wrote:
On 2011-12-13 23:08:43 +, Andrei Alexandrescu
said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (which was discussed and
rejected in this newsgroup) was miles
Jonathan M Davis:
> I tend to avoid const ranges precisely because they pretty much never work.
> I'd use them more if a tail-const version of them were easily obtainable -
This is what I was trying to answer to Andrei :-)
Bye,
bearophile
On 13.12.2011 23:17, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I believe the English version is "Out of the frying pan, into the fire" :)
The Norwegian ver
On 12/14/2011 12:35 AM, Peter Alexander wrote:
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
wrote:
There's a phrase in Romanian that quit
On Tuesday, December 13, 2011 21:36:43 Michel Fortin wrote:
> On 2011-12-13 23:08:43 +, Andrei Alexandrescu
>
> said:
> > We could have inferred property intention from the code pattern,
> > without requiring any keyword. That solution (which was discussed and
> > rejected in this newsgroup)
On 2011-12-13 23:08:43 +, Andrei Alexandrescu
said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (which was discussed and
rejected in this newsgroup) was miles ahead from the drivel of
@property we have now.
By "code patt
On Sunday, December 11, 2011 02:05:08 Andrei Alexandrescu wrote:
> On 12/11/11 1:30 AM, Jonathan M Davis wrote:
> > On Sunday, December 11, 2011 01:16:28 Andrei Alexandrescu wrote:
> >> To truly confer user-defined types the same capability, we should
> >> define
> >> opPassByValue() which is impli
On 13/12/11 11:11 PM, Timon Gehr wrote:
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I be
On 12/14/2011 12:14 AM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I believe the English version is "Out of the
On 12/13/11 5:14 PM, Peter Alexander wrote:
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I believe the English version is "Out of the fry
On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote:
There's a phrase in Romanian that quite applies: "From the lake into
the well".
I believe the English version is "Out of the frying pan, into the fire" :)
Inconsequential s
On Monday, 12 December 2011 at 15:32:05 UTC, Jakob Ovrum wrote:
(Unrelated side-note: I am using the web interface and I'm not
well seasoned with using newsgroups, is there a better way to
reply to multiple small posts than replying to each
individually like I just did? I apologize if I'm being
On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
wrote:
There's a phrase in Romanian that quite applies: "From the lake
into the well".
I believe the English version is "Out of the frying pan, into the
fire" :)
Inconsequential space-filler opinion: I am OK with @property,
m
On 12/13/11 2:25 PM, Jonathan M Davis wrote:
On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
On 12/13/11 10:32 AM, Jonathan M Davis wrote:
On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
On Monday, December 12, 20
On Tuesday, December 13, 2011 12:25:12 Jonathan M Davis wrote:
> On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
> > On 12/13/11 10:32 AM, Jonathan M Davis wrote:
> > > On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> > >> On 12/12/11 1:12 PM, Jonathan M Davis wr
On Tuesday, December 13, 2011 14:02:51 Andrei Alexandrescu wrote:
> On 12/13/11 10:32 AM, Jonathan M Davis wrote:
> > On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> >> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> >>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wr
On 12/13/11 10:32 AM, Jonathan M Davis wrote:
On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
Insisting on the current property semantics was a sizeable mistake of
thi
On Monday, December 12, 2011 18:00:35 Andrei Alexandrescu wrote:
> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> > On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> >> Insisting on the current property semantics was a sizeable mistake of
> >> this community, and I am sorry we gave
On 12/13/2011 01:08 AM, Steven Schveighoffer wrote:
On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu
wrote:
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
Insisting on the current property semantics was a sizeable mistake
On 13.12.2011 02:39, Jonathan M Davis wrote:
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
It's actually not 'save' being a noun that's the problem. I just
thought of a counter-example:
--- struct Foo { // the data Bar data[];
// save data on shutdown? @property bool save() { return save
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
> It's actually not 'save' being a noun that's the problem. I just
> thought of a counter-example:
>
> ---
> struct Foo {
> // the data
> Bar data[];
>
> // save data on shutdown?
> @property bool save() { return save_; }
> @property bool save(b
On 12.12.2011 20:03, Jonathan M Davis wrote:
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
On 12/12/11 9:09 AM, torhu wrote:
> On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>> On 12/12/11 6:24 AM, torhu wrote:
>>> save being a property is a stupid inconsistency.
>>
On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu
wrote:
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
Insisting on the current property semantics was a sizeable mistake of
this community, and I am sorry we gave into it.
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
Insisting on the current property semantics was a sizeable mistake of
this community, and I am sorry we gave into it.
Aside from the fact that the behavior of -property isn't the defau
On Monday, December 12, 2011 17:24:38 Jakob Ovrum wrote:
> I'm still a beginner with ranges, but by my understanding and by
> what some people made it sound like, reasonable uses of save
> include some which are non-trivial. If this is true, then
> removing @property from save encourages people to
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> Insisting on the current property semantics was a sizeable mistake of
> this community, and I am sorry we gave into it.
Aside from the fact that the behavior of -property isn't the default, what's
the problem with @property?
- Jo
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
> On 12/12/11 9:09 AM, torhu wrote:
> > On 12.12.2011 15:43, Andrei Alexandrescu wrote:
> >> On 12/12/11 6:24 AM, torhu wrote:
> >>> save being a property is a stupid inconsistency.
> >>
> >> I'm not so sure.
> >>
> >> Andrei
> >
>
On 12/12/11 3:16 PM, Andrei Alexandrescu wrote:
On 12/12/11 9:09 AM, torhu wrote:
On 12.12.2011 15:43, Andrei Alexandrescu wrote:
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
Why? As far as I can tell, it's inconsistent with wh
On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu
wrote:
On 12/12/11 9:29 AM, Jakob Ovrum wrote:
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei
Alexandrescu wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a f
On 12/12/11 9:29 AM, Jakob Ovrum wrote:
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he shouldn't need
to know, it should be fast and
On 12.12.2011 16:16, Andrei Alexandrescu wrote:
On 12/12/11 9:09 AM, torhu wrote:
On 12.12.2011 15:43, Andrei Alexandrescu wrote:
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
Why? As far as I can tell, it's inconsistent w
On Monday, 12 December 2011 at 15:29:26 UTC, Jakob Ovrum wrote:
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei
Alexandrescu wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he
shouldn't need
to kno
On 12/12/2011 04:29 PM, Jakob Ovrum wrote:
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he shouldn't need
to know, it should be fast a
On Monday, 12 December 2011 at 15:21:31 UTC, Andrei Alexandrescu
wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
The old situation where you could
write complete nonsense code like `std.file.read = "foo.txt";`
is far
worse.
We could have defined a system much better than both.
Andrei
I def
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu
wrote:
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he
shouldn't need
to know, it should be fast and cheap, and return a consistent
value. A
On Monday, 12 December 2011 at 15:16:56 UTC, Adam D. Ruppe wrote:
On Monday, 12 December 2011 at 15:07:16 UTC, Jakob Ovrum wrote:
The old situation where you could write complete nonsense code
like `std.file.read = "foo.txt";` is far worse.
If we start removing features because someone can use
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
The old situation where you could
write complete nonsense code like `std.file.read = "foo.txt";` is far
worse.
We could have defined a system much better than both.
Andrei
On Monday, 12 December 2011 at 15:07:16 UTC, Jakob Ovrum wrote:
The old situation where you could write complete nonsense code
like `std.file.read = "foo.txt";` is far worse.
If we start removing features because someone can use them
when deliberately obfuscating their code, we might as well
ju
On 12/12/11 9:09 AM, torhu wrote:
On 12.12.2011 15:43, Andrei Alexandrescu wrote:
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
Why? As far as I can tell, it's inconsistent with what properties are
used like in other programming
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
If the programmer sees just "r.save", he
doesn't know whether it's a field or a property, and he shouldn't need
to know, it should be fast and cheap, and return a consistent value. As
far as I know, this isn't always true for save
Why? Save does behave li
On 12.12.2011 15:43, Andrei Alexandrescu wrote:
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
Why? As far as I can tell, it's inconsistent with what properties are
used like in other programming languages. Saving something is
On Monday, 12 December 2011 at 14:46:17 UTC, Andrei Alexandrescu
wrote:
On 12/12/11 6:49 AM, Manu wrote:
I think every opportunity should be taken to make important
breaking
changes while the community is as small as it is.
Changing from r.save to r.save() is NOT an important change. It
make
On Monday, 12 December 2011 at 12:38:10 UTC, Jakob Ovrum wrote:
Furthermore, there weren't even a way to enforce the property
syntax until lately, and it's still not enabled by default.
The real WTF is that someone decided @property should be used for
anything more than disambiguation.
On 12/12/11 6:49 AM, Manu wrote:
I think every opportunity should be taken to make important breaking
changes while the community is as small as it is.
Changing from r.save to r.save() is NOT an important change. It makes no
semantic difference, marks no progress, and has no consequence.
Ins
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
On 2011-12-11 13:46, Michel Fortin wrote:
On 2011-12-11 07:16:28 +, Andrei Alexandrescu
said:
On 12/10/11 5:20 PM, Michel Fortin wrote:
Also seems strange to me that class references aren't included in that
list, but then I though about how tail-const still doesn't work with
objects. You'
On Sun, 11 Dec 2011 16:34:34 -0500, Jonathan M Davis
wrote:
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
> On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
>> We decided to fix this issue by automatically shedding the top-level
>> cons
On Sun, 11 Dec 2011 06:16:33 -0500, Mehrdad wrote:
On 12/11/2011 2:56 AM, David Nadlinger wrote:
On 12/11/11 10:04 AM, Mehrdad wrote:
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Ah good point, I forgot about that. Idk then.
(You forg
On 2011-12-12 12:38:09 +, "Jakob Ovrum" said:
Furthermore, there weren't even a way to enforce the property syntax
until lately, and it's still not enabled by default. If we change it
right now, people still have time to adapt before the
backwards-compatibility argument even kicks in (no
On 12 December 2011 14:24, torhu wrote:
> On 11.12.2011 22:24, Jonathan M Davis wrote:
> ...
>
> It was debated some time ago, and it ended up being a property. The fact
>> that
>> save is an action verb and not a noun automatically disqualifies it as a
>> property IMHO, but it was made into a p
On Monday, 12 December 2011 at 12:24:53 UTC, torhu wrote:
On 11.12.2011 22:24, Jonathan M Davis wrote:
...
It was debated some time ago, and it ended up being a
property. The fact that
save is an action verb and not a noun automatically
disqualifies it as a
property IMHO, but it was made into a
On 11.12.2011 22:24, Jonathan M Davis wrote:
...
It was debated some time ago, and it ended up being a property. The fact that
save is an action verb and not a noun automatically disqualifies it as a
property IMHO, but it was made into a property, and we're pretty much stuck
with it at some point
On 12/11/2011 11:24 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 14:54:27 Tobias Pankrath wrote:
Specifically:
"Properties should behave as if they are fields; if the method cannot,
it should not be changed to a property.
Methods are better than properties in the following situation
On 12/12/2011 12:33 AM, deadalnix wrote:
I think you misunderstood the idea. The point was to remove constness of
something passed by value, as long as it possible (native types, pointer
(but not pointee), slices (but not what is in the slice), structs as
long as they have no indirection in them)
On 12/11/11 4:19 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 23:13:39 Timon Gehr wrote:
On 12/11/2011 10:34 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu
Le 11/12/2011 22:34, Jonathan M Davis a écrit :
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an arra
On 12/11/2011 11:19 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 23:13:39 Timon Gehr wrote:
On 12/11/2011 10:34 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandres
On Sunday, December 11, 2011 23:13:39 Timon Gehr wrote:
> On 12/11/2011 10:34 PM, Jonathan M Davis wrote:
> > On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
> >> On 12/11/11 9:46 AM, dsimcha wrote:
> >>> On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
> We decided to fix th
On 12/11/2011 10:34 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an arra
On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
> On 12/11/11 9:46 AM, dsimcha wrote:
> > On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
> >> We decided to fix this issue by automatically shedding the top-level
> >> const when passing an array or a pointer by value into a functi
On Sunday, December 11, 2011 14:54:27 Tobias Pankrath wrote:
> > Specifically:
> >
> > "Properties should behave as if they are fields; if the method cannot,
> > it should not be changed to a property.
> > Methods are better than properties in the following situations:
> >
> > - Calling the metho
On 12/11/2011 05:34 PM, Andrei Alexandrescu wrote:
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
Really silly questio
Le 11/12/2011 17:34, Andrei Alexandrescu a écrit :
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
Really silly questio
On 12/11/11 9:46 AM, dsimcha wrote:
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
Really silly question: Why not do the same for primitives (int, float,
c
On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
Really silly question: Why not do the same for primitives (int, float,
char, etc.) or even structs without
> Specifically:
>
> "Properties should behave as if they are fields; if the method cannot,
> it should not be changed to a property.
> Methods are better than properties in the following situations:
>
> - Calling the method two times in succession creates different results.
> - The method perform
On 2011-12-11 07:16:28 +, Andrei Alexandrescu
said:
On 12/10/11 5:20 PM, Michel Fortin wrote:
Also seems strange to me that class references aren't included in that
list, but then I though about how tail-const still doesn't work with
objects. You'd need my const(Object)ref patch to make t
On 12/11/2011 1:54 AM, Walter Bright wrote:
Try the new beta
http://ftp.digitalmars.com/dmd2beta.zip
WHOA nice, the reduce() example worked!! :D Thanks for taking the time
to fix it!
I'll post if I come across similar/related problems. :)
On 12/11/2011 2:56 AM, David Nadlinger wrote:
On 12/11/11 10:04 AM, Mehrdad wrote:
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Ah good point, I forgot about that. Idk then.
(You forgot the parentheses though. :P)
No, it's correct like
On 12/11/11 10:04 AM, Mehrdad wrote:
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Ah good point, I forgot about that. Idk then.
(You forgot the parentheses though. :P)
No, it's correct like that, save() is a @property.
Even though I re
On 12/11/2011 1:04 AM, Mehrdad wrote:
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Andrei
Ah good point, I forgot about that. Idk then.
(You forgot the parentheses though. :P)
Try the new beta
http://ftp.digitalmars.com/dmd2beta.zip
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Andrei
Ah good point, I forgot about that. Idk then.
(You forgot the parentheses though. :P)
On 12/11/11 2:36 AM, Mehrdad wrote:
On 12/11/2011 12:14 AM, Andrei Alexandrescu wrote:
What do you do inside that method? It's reasonable to not expect to
change it.
Andrei
Not sure right now, but something along the lines of
auto copy = this;
foreach (v; copy)
;
sounds like code I've d
On 12/11/11 2:48 AM, bearophile wrote:
Andrei Alexandrescu:
I'm not sure. How many times have you been in a place in life
where you had a const range on your hands, that's not an array? I
haven't.
How many times I have used reduce or map on constant arrays in D2?
Only few times, using a cast(
Andrei Alexandrescu:
> I'm not sure. How many times have you been in a place in life where you
> had a const range on your hands, that's not an array? I haven't.
How many times I have used reduce or map on constant arrays in D2? Only few
times, using a cast(). Now I am using them.
Bye,
bearoph
On 12/11/2011 12:14 AM, Andrei Alexandrescu wrote:
What do you do inside that method? It's reasonable to not expect to
change it.
Andrei
Not sure right now, but something along the lines of
auto copy = this;
foreach (v; copy)
;
sounds like code I've definitely seen befo
On 12/11/11 2:08 AM, Mehrdad wrote:
On 12/11/2011 12:05 AM, Andrei Alexandrescu wrote:
I'm not sure. How many times have you been in a place in life where
you had a const range on your hands, that's not an array? I haven't.
Andrei
Hmmm.. isn't that precisely what happens when you define a 'co
On 12/11/2011 12:05 AM, Andrei Alexandrescu wrote:
I'm not sure. How many times have you been in a place in life where
you had a const range on your hands, that's not an array? I haven't.
Andrei
Hmmm.. isn't that precisely what happens when you define a 'const'
method for your (custom) range
On 12/11/11 1:30 AM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 01:16:28 Andrei Alexandrescu wrote:
To truly confer user-defined types the same capability, we should define
opPassByValue() which is implicitly invoked whenever an object is passed
by value into a function. By default tha
On Sunday, December 11, 2011 01:16:28 Andrei Alexandrescu wrote:
> On 12/10/11 5:20 PM, Michel Fortin wrote:
> > On 2011-12-10 21:47:13 +, Andrei Alexandrescu
> >
> > said:
> >> We decided to fix this issue by automatically shedding the top-level
> >> const when passing an array or a pointer
On 12/10/11 5:20 PM, Michel Fortin wrote:
On 2011-12-10 21:47:13 +, Andrei Alexandrescu
said:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
It seems strange that if you implemented the exact same se
On 12/10/11 6:24 PM, kenji hara wrote:
Posted a test patch to realize the suggestion.
https://github.com/D-Programming-Language/dmd/pull/554
Kenji Hara
Many thanks, Kenji, for executing so fast on this!
Andrei
Posted a test patch to realize the suggestion.
https://github.com/D-Programming-Language/dmd/pull/554
Kenji Hara
2011/12/11 kenji hara :
> OK. I agree to the suggestion.
>
> I've been afraid that increasing IFTI rule is making the language
> learning difficult.
> It comes from the experience from
On 2011-12-10 21:47:13 +, Andrei Alexandrescu
said:
We decided to fix this issue by automatically shedding the top-level
const when passing an array or a pointer by value into a function.
It seems strange that if you implemented the exact same semantic as an
a dynamic array or a pointer
OK. I agree to the suggestion.
I've been afraid that increasing IFTI rule is making the language
learning difficult.
It comes from the experience from implementing inout deduction for
template function.
But also it is useful that removing top const when passing arguments by value.
C++ precedent c
On Sunday, December 11, 2011 08:01:57 kenji hara wrote:
> 2011/12/11 bearophile :
> > kenji hara:
> >> It breaks IFTI rule,
> >
> > What do you mean?
>
> I mean following code comment will not become true.
>
> void func(T)(T prm){}
> void main(){
>X arg;
>func(arg); // T is deduced to t
On 12/10/2011 11:41 PM, Andrei Alexandrescu wrote:
On 12/10/11 4:31 PM, kenji hara wrote:
Treating whole constant arrays as ranges by automatically shedding the
top-level const is good.
But realizing it by language semantic change is definitely bad.It
breaks IFTI rule, and adding special case wi
2011/12/11 Andrei Alexandrescu :
> On 12/10/11 4:31 PM, kenji hara wrote:
>>
>> Treating whole constant arrays as ranges by automatically shedding the
>> top-level const is good.
>> But realizing it by language semantic change is definitely bad.It
>> breaks IFTI rule, and adding special case will m
2011/12/11 bearophile :
> kenji hara:
>
>> It breaks IFTI rule,
>
> What do you mean?
I mean following code comment will not become true.
void func(T)(T prm){}
void main(){
X arg;
func(arg); // T is deduced to typeof(arg)
}
>
>
>> and adding special case will make difficult to learn langu
1 - 100 of 109 matches
Mail list logo
