spir Wrote:
> >> > attribute funcName inputParams -> outputParams { body }
> > ReturnType funcAttributes funcName(params) { body }
>
> So what?
So there's no need for FP-style syntax to just disambiguate attribute placing.
> > BTW the problem is in separation of function attributes from retur
On 01/26/2011 11:02 AM, Kagamin wrote:
This "problem" happens because D belongs to the C-family of languages which
puts the return type_before_ the function name.
>
> Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
>
foobar Wrote:
> This "problem" happens because D belongs to the C-family of languages which
> puts the return type _before_ the function name.
>
> Languages that don't follow this syntactic convention (some would call it a
> mistake) have it very consistent and readable:
> attribute funcName i
so Wrote:
> > C++ is indeed complex and one of the reasons is its syntax (believe it
> > or not). There was even an academic project to re-syntax C++ with the
> > exact same semantics.
> > Of course it's not the only cause of complexity in C++ but it is
> > definitely one of the main ones.
>
C++ is indeed complex and one of the reasons is its syntax (believe it
or not). There was even an academic project to re-syntax C++ with the
exact same semantics.
Of course it's not the only cause of complexity in C++ but it is
definitely one of the main ones.
If that is the case, you are p
so Wrote:
> > Here's another perspective:
> > A professor that teaches introduction to CS in first semester to
> > students that never programmed before needs to choose a programing
> > language. One of the criteria for choosing which language to use is of
> > course the learning curve.
> >
Here's another perspective:
A professor that teaches introduction to CS in first semester to
students that never programmed before needs to choose a programing
language. One of the criteria for choosing which language to use is of
course the learning curve.
I'm sure you know that not all uni
so Wrote:
> > Boy you missed the point by about 2.5 light years..
>
> This can go forever as long as one of us resist to simple reasoning and
> analogy,
> and the other one has the energy to continue.
>
> > All I said is that Since D is English based (terminology, etc) it would
> > make sens
Boy you missed the point by about 2.5 light years..
This can go forever as long as one of us resist to simple reasoning and
analogy,
and the other one has the energy to continue.
All I said is that Since D is English based (terminology, etc) it would
make sense to follow a more English lik
On 01/25/2011 10:45 AM, Jens Mueller wrote:
I distinguish the following:
type qualifiers: const, immutable, maybe also inout
function attributes: pure, nothrow
storage class: ref, in, out, static
access qualifiers: private, package, protected, public, export
Nice & clear classification. Then, i
bearophile wrote:
> Jens Mueller:
>
> > I didn't have that impression reading the mentioned bug reports. It
> > seems there is more that I'm missing.
>
> See Walter answers here:
> http://d.puremagic.com/issues/show_bug.cgi?id=4070
I'm not getting it. In comment 1 Walter refers to const:, const
Jens Mueller:
> I didn't have that impression reading the mentioned bug reports. It
> seems there is more that I'm missing.
See Walter answers here:
http://d.puremagic.com/issues/show_bug.cgi?id=4070
Bye,
bearophile
Jonathan M Davis wrote:
> On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
> >
> > I do not know what are you referring to when you say function attributes.
> > I distinguish the following:
> > type qualifiers: const, immutable, maybe also inout
> > function attributes: pure, nothrow
> > st
On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
> > > Jonathan M Davis wrote:
> > > > On Monday 24 January 2011 12:08:29 Don wrote:
> > > > > Steven Schveighoffer wrote:
> > > > > > On Mon, 24 Jan 2011 13:3
Jens Mueller:
> all mean the same. And Walter seems to be unsure whether forbidding
> const void foo() is worth the trouble, isn't it?
> I see and felt the pain for newcomers to decipher the meaning of
> const void foo();
> I see two options:
Now I'd like to know what Andrei thinks about this.
B
so Wrote:
> > Look at this from a "It reads like English" prospective and not from a
> > "I'm an experienced c++ programmer and therefore already used to this
> > crap" perspective.
> > In other words, if you were just starting to learn your first
> > programming language, what would confuse
Jonathan M Davis wrote:
> On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Monday 24 January 2011 12:08:29 Don wrote:
> > > > Steven Schveighoffer wrote:
> > > > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > > > >
> > > > > wrote:
> > > > >> There
On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Monday 24 January 2011 12:08:29 Don wrote:
> > > Steven Schveighoffer wrote:
> > > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > > >
> > > > wrote:
> > > >> There are six, seven or more people that wish
Also, you can't do this in C++.
Which was my point.
Argh, hate it that you can't edit posts, ignore the second line.
C++ style aka Yoda style:
1. public double func(int input) const;
Also, you can't do this in C++.
Which was my point.
Look at this from a "It reads like English" prospective and not from a
"I'm an experienced c++ programmer and therefore already used to this
crap" perspective.
In other words, if you were just starting to learn your first
programming language, what would confuse you less?
If i was starting
Of course C++ has everything :-) See the trailing-return-type feature of
C++0x:
http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x
Bye,
bearophile
Now i am completely lost, i can't see any connection at all!
so Wrote:
> > C++ style aka Yoda style:
> > 1. public double func(int input) const;
> > 2. const double func(int input);
> > 3. const double func(int input) const;
> >
> > VS.
> > hypothetical left-to-right style:
> > 1. public const func (int input) -> (double);
> > 2. func (int input) -> (const
bearophile Wrote:
> foobar:
>
> > This "problem" happens because D belongs to the C-family of languages which
> > puts the return type _before_ the function name.
>
> Of course C++ has everything :-) See the trailing-return-type feature of
> C++0x:
> http://en.wikipedia.org/wiki/C%2B%2B0x#Alte
C++ style aka Yoda style:
1. public double func(int input) const;
2. const double func(int input);
3. const double func(int input) const;
VS.
hypothetical left-to-right style:
1. public const func (int input) -> (double);
2. func (int input) -> (const double);
3. const func (int input) -> (const
so Wrote:
> > This "problem" happens because D belongs to the C-family of languages
> > which puts the return type _before_ the function name.
>
> It has nothing to do with being a C-family language. C/C++ don't have
> this, and the rules are perfectly clear.
> It is just unifying two or more
foobar:
> This "problem" happens because D belongs to the C-family of languages which
> puts the return type _before_ the function name.
Of course C++ has everything :-) See the trailing-return-type feature of C++0x:
http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
http://stack
2011/1/24 foobar :
> This "problem" happens because D belongs to the C-family of languages which
> puts the return type _before_ the function name.
>
> Languages that don't follow this syntactic convention (some would call it a
> mistake) have it very consistent and readable:
> attribute funcName
On 01/24/2011 07:36 PM, bearophile wrote:
What other people think about this situation? Do you want const/immutable to be
required on the right, or do you prefer the current situation, or do you prefer
some other solution?
Comparing with C-like typing syntax that, I guess, are planned for dep
This "problem" happens because D belongs to the C-family of languages
which puts the return type _before_ the function name.
It has nothing to do with being a C-family language. C/C++ don't have
this, and the rules are perfectly clear.
It is just unifying two or more unrelated things in one s
Don Wrote:
> Steven Schveighoffer wrote:
> > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > wrote:
> >
> >> There are six, seven or more people that wish to do something about
> >> this situation. TDPL is the D2 reference, but few little changes over
> >> its first edition are acceptable
2011/1/24 Simen kjaeraas :
> The suggestion is only for const alone on the left-hand side. const: and
> const{} would not be affected by such a change.
You're right, it's not confusing at all. It makes perfect sense for
function attributes to go on the right. But then I'd like all of them
to go th
Jonathan M Davis wrote:
> On Monday 24 January 2011 12:08:29 Don wrote:
> > Steven Schveighoffer wrote:
> > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > >
> > > wrote:
> > >> There are six, seven or more people that wish to do something about
> > >> this situation. TDPL is the D2 referenc
Steven Schveighoffer:
> I think we have more important problems to worry about than this.
I agree. On the other hand in other languages I've seen that many small
troubles pile up and reduce the enjoyment of using a language.
Bye,
bearophile
On Monday 24 January 2011 12:08:29 Don wrote:
> Steven Schveighoffer wrote:
> > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> >
> > wrote:
> >> There are six, seven or more people that wish to do something about
> >> this situation. TDPL is the D2 reference, but few little changes over
> >> it
Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
wrote:
There are six, seven or more people that wish to do something about
this situation. TDPL is the D2 reference, but few little changes over
its first edition are acceptable if they improve the D language a little
I wouldn't say that I *prefer* the current solution, but the current
solution is not so bad that I need it changed.
It works fine, despite being confusing. If it wasn't consistent with
the rest of the attributes, I'd say it was in need of changes, but it
fits within the scheme already outl
I think we have more important problems to worry about than this.
IMHO fixing trivial issues first or as soon as possible is better.
Not saying this is one of them, i mean generally.
Torarin wrote:
2011/1/24 bearophile :
What other people think about this situation? Do you want
const/immutable to be required on the right, or do you prefer the
current situation, or do you prefer some other solution?
If const is required to go on the right, what do you do if you want to
On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
wrote:
There are six, seven or more people that wish to do something about this
situation. TDPL is the D2 reference, but few little changes over its
first edition are acceptable if they improve the D language a little.
- Trass3r: asks if the
On Mon, 24 Jan 2011 20:41:17 +0200, Torarin wrote:
2011/1/24 bearophile :
What other people think about this situation? Do you want
const/immutable to be required on the right, or do you prefer the
current situation, or do you prefer some other solution?
If const is required to go on the
2011/1/24 bearophile :
> What other people think about this situation? Do you want const/immutable to
> be required on the right, or do you prefer the current situation, or do you
> prefer some other solution?
If const is required to go on the right, what do you do if you want to
mark a bunch of
There are six, seven or more people that wish to do something about this
situation. TDPL is the D2 reference, but few little changes over its first
edition are acceptable if they improve the D language a little.
- Trass3r: asks if the code is ambiguous
- Jonathan M Davis: does't like it and puts
Jonathan M Davis wrote:
Only to humans. const applies to everything after it, unless there
are parentheses. In this case, 'everything' is Foo bar();
Not quite right. The return value is _not_ const in this case. It's
only the function which is affected. Try it and you'll see. The _only_
time
Trass3r Wrote:
> class F
> {
> const Foo bar();
> }
>
> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> member function that returns a Foo object"?
The const qualifier applies to the member being declared - the function in this
case. Usually transitivity rules come into pla
On Mon, 24 Jan 2011 09:39:16 -0500, Jonathan M Davis
wrote:
On Monday 24 January 2011 06:27:34 Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
wrote:
> On Monday 24 January 2011 05:56:49 Trass3r wrote:
>> class F
>> {
>> const Foo bar();
>> }
>>
>> Isn't
On Monday 24 January 2011 06:45:27 Andrej Mitrovic wrote:
> Perhaps it would be less ambiguous if we turned const/immutable for
> functions into annotations:
>
> @const Foo bar(); //const function
> @immutable Foo bar(); //immutable function
> @immutable const(Foo) bar(); //immutable function with
Perhaps it would be less ambiguous if we turned const/immutable for
functions into annotations:
@const Foo bar(); //const function
@immutable Foo bar(); //immutable function
@immutable const(Foo) bar(); //immutable function with const return value
@const const(Foo) bar(); //const function with con
On Monday 24 January 2011 06:27:34 Steven Schveighoffer wrote:
> On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
>
> wrote:
> > On Monday 24 January 2011 05:56:49 Trass3r wrote:
> >> class F
> >> {
> >> const Foo bar();
> >> }
> >>
> >> Isn't this ambiguous? "returns a const Foo object" vs.
On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
wrote:
On Monday 24 January 2011 05:56:49 Trass3r wrote:
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
When using const or immutable in a func
Simen kjaeraas wrote:
> Trass3r wrote:
>
> >class F
> >{
> >const Foo bar();
> >}
> >
> >Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> >member function that returns a Foo object"?
>
> Only to humans. const applies to everything after it, unless there
> are parentheses. In
On Monday 24 January 2011 06:02:13 Simen kjaeraas wrote:
> Trass3r wrote:
> > class F
> > {
> > const Foo bar();
> > }
> >
> > Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> > member function that returns a Foo object"?
>
> Only to humans. const applies to everything after
On Monday 24 January 2011 05:56:49 Trass3r wrote:
> class F
> {
> const Foo bar();
> }
>
> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> member function that returns a Foo object"?
When using const or immutable in a function signature, it _always_ applies to
the function,
Trass3r wrote:
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
Only to humans. const applies to everything after it, unless there
are parentheses. In this case, 'everything' is Foo bar();
I do agree
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
55 matches
Mail list logo
