On 29/11/2010 04:19, Jack wrote:
The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others' posts have
stopped or stagnated into that cesspool of threaded
On 10/12/2010 20:31, Andrei Alexandrescu wrote:
On 12/10/10 10:41 AM, Bruno Medeiros wrote:
On 30/11/2010 20:47, Andrei Alexandrescu wrote:
Same discussion goes about non-nullable. We don't need the compiler to
understand non-nullable types, we need to imbue the compiler with the
ability to en
On 12/10/10 10:41 AM, Bruno Medeiros wrote:
On 30/11/2010 20:47, Andrei Alexandrescu wrote:
Same discussion goes about non-nullable. We don't need the compiler to
understand non-nullable types, we need to imbue the compiler with the
ability to enforce arbitrary user-defined state invariants, no
On 09/12/2010 18:13, Steven Schveighoffer wrote:
On Thu, 09 Dec 2010 12:07:28 -0500, Bruno Medeiros
wrote:
On 29/11/2010 22:53, Walter Bright wrote:
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months
On Fri, 10 Dec 2010 13:00:01 -0500, Bruno Medeiros
wrote:
On 09/12/2010 18:12, Steven Schveighoffer wrote:
On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros
wrote:
On 29/11/2010 21:13, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin wrote:
Steven Schveighoffer
On 30/11/2010 20:47, Andrei Alexandrescu wrote:
Same discussion goes about non-nullable. We don't need the compiler to
understand non-nullable types, we need to imbue the compiler with the
ability to enforce arbitrary user-defined state invariants, non-null
being one of them.
That would be gr
On 09/12/2010 18:12, Steven Schveighoffer wrote:
On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros
wrote:
On 29/11/2010 21:13, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin wrote:
Steven Schveighoffer Wrote:
My favorite in recent times is:
@tail const(C) tailc
On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros
wrote:
On 29/11/2010 21:13, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin wrote:
Steven Schveighoffer Wrote:
My favorite in recent times is:
@tail const(C) tailconst;
Tail const is a type constructor, but I
On Thu, 09 Dec 2010 12:07:28 -0500, Bruno Medeiros
wrote:
On 29/11/2010 22:53, Walter Bright wrote:
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months trying to
make it work, and I learned my lesson
On 29/11/2010 22:53, Walter Bright wrote:
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months trying to
make it work, and I learned my lesson.
Even without knowing anything about DMD internals, I would
On 29/11/2010 21:13, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin wrote:
Steven Schveighoffer Wrote:
My favorite in recent times is:
@tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations
should evolve that far.
What I l
On 05.12.2010 05:37, Json wrote:
> spir wrote:
>> On Mon, 29 Nov 2010 08:17:23 +0300
>> "Denis Koroskin" <2kor...@gmail.com> wrote:
>>
>>> I'd go with omissible parens. There are SO many bugs and stuff that
>>> can't be worked around due to this.
>>
>> +++
>>
>> (Once again, allowing a few less key
trollollol wrote:
[]
Don't fuck with me. I am in no fucking mood.
> Thus, trolling. It's so lovely to see the stupidest shitheads in this
> community fall for the traps. Those sheeple without any independent opinions,
> head full of marketing lies.
It's ok to make the case for D trolls, but consider you have a false
understanding of the "sheeple" side. When
For example in the thread about Eiffel language he told that he has no
time to study Eiffel. This is a major W-T-F. The first priority of a
language designer should be the best possible language spec, later comes
good implementation and other issues. Once the fucked up design is set
in ston
trollollol Wrote:
> Sat, 04 Dec 2010 22:52:11 -0600, Json wrote:
>
> > bearophile wrote:
> >> Walter:
> >>
> >>> There are a thousand languages out there. I could spend multiple
> >>> lifetimes studying them, and then have to start all over with the new
> >>> crop of languages, and accomplish abs
Sat, 04 Dec 2010 22:52:11 -0600, Json wrote:
> bearophile wrote:
>> Walter:
>>
>>> There are a thousand languages out there. I could spend multiple
>>> lifetimes studying them, and then have to start all over with the new
>>> crop of languages, and accomplish absolutely nothing.
>>
>> It's a matte
Steven Schveighoffer wrote:
> On Sun, 28 Nov 2010 23:19:44 -0500, Jack wrote:
>
>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>> pick up the ball and run with it, don't be shy. I expect Walter and
>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>>
bearophile wrote:
> Walter:
>
>> There are a thousand languages out there. I could spend multiple
>> lifetimes studying them, and then have to start all over with the
>> new crop of languages, and accomplish absolutely nothing.
>
> It's a matter of balance.
No it isn't.
> If you want to design so
Walter Bright wrote:
> architect wrote:
>> You should study Eiffel that much.
>
> There are a thousand languages out there. I could spend multiple
> lifetimes studying them, and then have to start all over with the new
> crop of languages, and accomplish absolutely nothing.
Why persist in this? Yo
Walter Bright wrote:
> Denis Koroskin wrote:
>> I'd go with omissible parens. There are SO many bugs and stuff that
>> can't be worked around due to this.
>
> For function calls? Yeah, I fell into that one. Oops. I should have
> learned my lesson with the problems that C has with implicitly taking
Gary Whatmore wrote:
> Jack Wrote:
>
>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>> pick up the ball and run with it, don't be shy. I expect Walter and
>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>> have stopped or stagnated into that cesspoo
Walter Bright wrote:
> Robert Jacques wrote:
>> D's omissible parenthesis strike me as being half-way between C#'s
>> properties and Eiffel's Uniform Access Principle. Given Eiffel's
>> influence on D, was there a reason why you didn't implement the
>> uniform access principal instead of omissible
spir wrote:
> On Mon, 29 Nov 2010 08:17:23 +0300
> "Denis Koroskin" <2kor...@gmail.com> wrote:
>
>> I'd go with omissible parens. There are SO many bugs and stuff that
>> can't be worked around due to this.
>
> +++
>
> (Once again, allowing a few less key-strokes makes a language
> uselessly compli
Gary Whatmore wrote:
> Jack Wrote:
>
>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>> pick up the ball and run with it, don't be shy. I expect Walter and
>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>> have stopped or stagnated into that cesspoo
Denis Koroskin wrote:
> On Mon, 29 Nov 2010 07:19:44 +0300, Jack wrote:
>
>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>> pick up the ball and run with it, don't be shy. I expect Walter and
>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>> have
Jonathan M Davis wrote:
> On Sunday 28 November 2010 20:19:44 Jack wrote:
>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>> pick up the ball and run with it, don't be shy. I expect Walter and
>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>> have s
bearophile Wrote:
> Walter:
>
> > There are a thousand languages out there. I could spend multiple lifetimes
> > studying them, and then have to start all over with the new crop of
> > languages,
> > and accomplish absolutely nothing.
>
> It's a matter of balance. If you want to design someth
Walter:
> There are a thousand languages out there. I could spend multiple lifetimes
> studying them, and then have to start all over with the new crop of
> languages,
> and accomplish absolutely nothing.
It's a matter of balance. If you want to design something new you need to keep
yourself
architect wrote:
You should study Eiffel that much.
There are a thousand languages out there. I could spend multiple lifetimes
studying them, and then have to start all over with the new crop of languages,
and accomplish absolutely nothing.
Walter Bright Wrote:
> Robert Jacques wrote:
> > D's omissible parenthesis strike me as being half-way between C#'s
> > properties and Eiffel's Uniform Access Principle. Given Eiffel's
> > influence on D, was there a reason why you didn't implement the uniform
> > access principal instead of om
Robert Jacques wrote:
On Tue, 30 Nov 2010 23:11:32 -0500, Walter Bright
wrote:
Robert Jacques wrote:
D's omissible parenthesis strike me as being half-way between C#'s
properties and Eiffel's Uniform Access Principle. Given Eiffel's
influence on D, was there a reason why you didn't implemen
On Tue, 30 Nov 2010 23:11:32 -0500, Walter Bright
wrote:
Robert Jacques wrote:
D's omissible parenthesis strike me as being half-way between C#'s
properties and Eiffel's Uniform Access Principle. Given Eiffel's
influence on D, was there a reason why you didn't implement the uniform
acce
Robert Jacques wrote:
D's omissible parenthesis strike me as being half-way between C#'s
properties and Eiffel's Uniform Access Principle. Given Eiffel's
influence on D, was there a reason why you didn't implement the uniform
access principal instead of omissible parenthesis?
I haven't studie
On Tue, 30 Nov 2010 14:36:58 -0500, Walter Bright
wrote:
Denis Koroskin wrote:
I'd go with omissible parens. There are SO many bugs and stuff that
can't be worked around due to this.
For function calls? Yeah, I fell into that one. Oops. I should have
learned my lesson with the problems th
On 11/30/10 15:24 CST, Steven Schveighoffer wrote:
Why is the frequency questionable? Isn't every use of string an example
of tail-immutable? Isn't string used everywhere?
That's a very good argument.
Andrei
On 30-nov-10, at 22:24, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 15:47:22 -0500, Andrei Alexandrescu > wrote:
On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
No, that's not what I'm saying. Creating a language-based tail-const
solution *unifies* all references, including any smart
On Tuesday, November 30, 2010 12:47:22 Andrei Alexandrescu wrote:
> On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
> > On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu
> >
> > wrote:
> >> On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
> >>> On Tue, 30 Nov 2010 10:36:53 -0500, Andrei
bearophile wrote:
- It lacks is ( Type : TypeSpecialization , TemplateParameterList ) and
is ( Type == TypeSpecialization , TemplateParameterList )
I think is() needs less stuff, not more. The functionality needs to be
moved to a nicer syntax (and according to Andrei a better semantics
On 11/30/10 3:23 PM, bearophile wrote:
Andrei:
Wonder how the reply is related to the quote.
Sorry, I meant that if your purpose is to "allow many good designs to
expressible as easily as possible" you risk creating a puzzle
language as Scheme or Forth. So you have to be careful in how much
f
Michel Fortin:
> I wonder how you determined it was "rare in practice". My attempts at
> using const and immutable with objects had Rebindable everywhere.
I agree that in my code with many object references that uses const/immutable
everywhere possible, the desire to use Rebindable is not rare.
"Walter Bright" wrote in message
news:id3jmo$s0...@digitalmars.com...
> Steven Schveighoffer wrote:
>> On Mon, 29 Nov 2010 17:53:19 -0500, Walter Bright
>> wrote:
>>
>>> Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
>>>
>>> The source to DMD is there. Fee
On 2010-11-30 15:47:22 -0500, Andrei Alexandrescu
said:
We were well aware of the tail const issue, and we made the executive
decision that we will punt on it on account of it being relatively rare
in practice, and partially addressable with Rebindable.
I wonder how you determined it was "r
On Tue, 30 Nov 2010 15:47:22 -0500, Andrei Alexandrescu
wrote:
On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
No, that's not what I'm saying. Creating a language-based tail-const
solution *unifies* all references, including any smart references you
can create. I can say tail-const anyth
Andrei:
> Wonder how the reply is related to the quote.
Sorry, I meant that if your purpose is to "allow many good designs to
expressible as easily as possible" you risk creating a puzzle language as
Scheme or Forth. So you have to be careful in how much flexibility you give to
your language.
On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu
wrote:
On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
wrote:
I agree that the problem is difficult but disagree with the angl
On 11/30/10 1:22 PM, Michel Fortin wrote:
On 2010-11-30 10:36:53 -0500, Andrei Alexandrescu
said:
Implementing this is already hard when const is always a type modifier.
If constness is sometime expressed as a type modifier and sometime
expressed as some kind of smart reference struct, it can on
Denis Koroskin wrote:
I'd go with omissible parens. There are SO many bugs and stuff that
can't be worked around due to this.
For function calls? Yeah, I fell into that one. Oops. I should have learned my
lesson with the problems that C has with implicitly taking the function's address.
Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 17:53:19 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months trying to
make it work, and I learned my lesson.
1. I don't
On 2010-11-30 10:36:53 -0500, Andrei Alexandrescu
said:
On 11/29/10 7:52 PM, Michel Fortin wrote:
Now consider this generic code that uses Unqual:
T[] giveMeASortedArray(alias Predicate, T)(T[] t) {
// creating new array of the same length but with assignable elements
auto copy = new Unqual!
On Tuesday, November 30, 2010 10:56:41 Steven Schveighoffer wrote:
> On Tue, 30 Nov 2010 13:46:31 -0500, Jonathan M Davis
>
> wrote:
> > Personally, I think that an in-language solution would definitely be
> > better and
> > more in line with other language features than trying to fix the issue
>
On Tue, 30 Nov 2010 13:46:31 -0500, Jonathan M Davis
wrote:
Personally, I think that an in-language solution would definitely be
better and
more in line with other language features than trying to fix the issue
in a
library. This really does look like a core language issue which we
could
On Tuesday, November 30, 2010 10:38:43 Steven Schveighoffer wrote:
> On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu
>
> wrote:
> > On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
> >> On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
> >>
> >> wrote:
> >>> I agree that the prob
On Tuesday, November 30, 2010 10:29:57 Simen kjaeraas wrote:
> Steven Schveighoffer wrote:
> > On Tue, 30 Nov 2010 13:13:47 -0500, Steven Schveighoffer
> >
> > wrote:
> >> IMO opinion,
> >
> > IMO opinion? Hm... wonder what that O stands for :D
>
> Own?
Nah. Other. He's got two opinions. But
On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu
wrote:
On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
wrote:
I agree that the problem is difficult but disagree with the angle.
This is not the challenge, and it is not only
Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 13:13:47 -0500, Steven Schveighoffer
wrote:
IMO opinion,
IMO opinion? Hm... wonder what that O stands for :D
Own?
--
Simen
On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
wrote:
I agree that the problem is difficult but disagree with the angle.
This is not the challenge, and it is not only mine to take. To the
extent we're interested in making D a successfu
On 11/30/10 12:09 PM, bearophile wrote:
Andrei:
The key is to navigate such that as many good designs are
expressible as easily as possible.
Very flexible designs are often made of very small parts that need
lot of brain to be combined to form something useful (see Scheme
language, or certain
On Tue, 30 Nov 2010 13:13:47 -0500, Steven Schveighoffer
wrote:
IMO opinion,
IMO opinion? Hm... wonder what that O stands for :D
-Steve
On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
wrote:
I agree that the problem is difficult but disagree with the angle. This
is not the challenge, and it is not only mine to take. To the extent
we're interested in making D a successful language, we're all on the
same boat, so t
Andrei:
> The key is to navigate such that as many good designs are expressible as
> easily as
> possible.
Very flexible designs are often made of very small parts that need lot of brain
to be combined to form something useful (see Scheme language, or certain toys).
They become almost puzzles
Simen kjaeraas:
> In my opinion, the syntax for is() is not all that bad.
Every time I have to use is() for something a bit more complex than just type
equivalence, I have to go read the D docs, despite I have used it many times.
But now I have memorized most other parts of D syntax.
> - It l
Simen kjaeraas:
> The problem with such a solution is that the compiler needs to evaluate
> the 'in' clause differently from all other code, as code further down in
> the 'in' clause could use parameters in a way that would be illegal at
> compile-time. Hence the new keyword
I see.
> or, for gi
On 11/29/10 7:52 PM, Michel Fortin wrote:
On 2010-11-29 14:03:27 -0500, Andrei Alexandrescu
said:
For instance, here's a tricky question: should Unqual!(const C) give you
a const(C), a Rebindable!(const C), or simply C?
C.
Now, what should
const(Unqual!(immutable C)) give you?
const(C).
bearophile wrote:
I think the syntax of is() is awful and I'd like to shoot it.
In my opinion, the syntax for is() is not all that bad. However:
- It lacks is ( Type : TypeSpecialization , TemplateParameterList ) and
is ( Type == TypeSpecialization , TemplateParameterList )
- It does not
bearophile wrote:
I like very much the idea of constraint blocks. Much better than
expanding func header line, reuses an existing syntactic construct, and
far cleaner.
But I'd like that syntax to allow for an error message for each
constraint. So it becomes like contract programming, don
On Mon, 29 Nov 2010 17:53:19 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months trying to
make it work, and I learned my lesson.
1. I don't blame you, spending months
spir:
> Andrej Mitrovic:
>
> > constraint
> > {
> > isDynamicArray(a);
> > isIterable(a);
> > }
> > body
> > {
> > ...
> > }
> I like very much the idea of constraint blocks. Much better than expanding
> func header line, reuses an existing syntactic construct, and far cleaner.
But
On Mon, 29 Nov 2010 07:13:20 -0500
bearophile wrote:
> D has had the very unusual chance to fix itself, with the D2 language not
> backward compatible. But then it was finalized too much early, this is in my
> opinion the greatest D2 mistake. D2 is a C++-class language, so it's large
> and com
On Mon, 29 Nov 2010 12:31:42 +
Andrej Mitrovic wrote:
> constraint
> {
> isDynamicArray(a);
> isIterable(a);
> }
> body
> {
> ...
> }
>
> So maybe every statement would be checked for the return value, and
> you would get the exact line where a constraint failed when
> instantiat
On Mon, 29 Nov 2010 07:18:42 -0500
bearophile wrote:
> > * Template pattern matching is incomplete
>
> I don't understand this, please explain better. But I think the syntax of
> is() is awful and I'd like to shoot it.
+++
(I think it is not even fixable; the issue may not be syntactic. Rat
On Mon, 29 Nov 2010 08:17:23 +0300
"Denis Koroskin" <2kor...@gmail.com> wrote:
> I'd go with omissible parens. There are SO many bugs and stuff that can't
> be worked around due to this.
+++
(Once again, allowing a few less key-strokes makes a language uselessly
complicated, harder to read, h
On Mon, 29 Nov 2010 16:43:01 -0500, Andrei Alexandrescu
wrote:
On 11/29/10 3:25 PM, Manfred_Nowak wrote:
Daniel Gibson wrote:
"with" shouldn't be much of a problem anymore.
import std.stdio;
struct X{ int a, b, c;}
struct Y{ int a, b;}
void main(){
X x;
Y y;
with( x){
c= 2;
On 2010-11-29 14:03:27 -0500, Andrei Alexandrescu
said:
For instance, here's a tricky question: should Unqual!(const C) give you
a const(C), a Rebindable!(const C), or simply C?
C.
Now, what should
const(Unqual!(immutable C)) give you?
const(C).
As I thought.
Now consider this generic
On 11/30/10, Simen kjaeraas wrote:
> Andrej Mitrovic wrote:
>
>>> Which error message should I show?
>>>
>> I'm not sure what you're getting at. :)
> [snip]
>> But anyway it's just an idea and I'm probably missing something
>> important, I haven't used D in a while..
>
> I believe you are missing
Andrej Mitrovic wrote:
Which error message should I show?
I'm not sure what you're getting at. :)
[snip]
But anyway it's just an idea and I'm probably missing something
important, I haven't used D in a while..
I believe you are missing that more templates could bear the same
name, and the
On 11/29/10, Simen kjaeraas wrote:
> Andrej Mitrovic wrote:
>
>> Why not do the same for templates? Something like this:
>>
>> void foo(A, B, C)(A a, B b, C c)
>> constraint
>> {
>> isDynamicArray(a);
>> isIterable(a);
>>
>> }
>
> Consider:
>
> void foo( A )( A a )
> constraint {
>isB
Daniel Gibson wrote:
> Jack schrieb:
>> Andrei Alexandrescu wrote:
>>> On 11/28/10 10:19 PM, Jack wrote:
The post "C#'s greatest mistakes" prompts/begs this post. Have at
it, pick up the ball and run with it, don't be shy. I expect
Walter and Andrei to answer (if Walter and Andrei so
Andrei Alexandrescu wrote:
> please submit this as a bug report
No, thanks. I never liked the semantic of `with'. But a nearly perfect
semantic has been choosen for the `import's.
Please extend the scope of `import' for the name spaces resulting out of
expressions to get rid of `with'.
-manfr
Steven Schveighoffer wrote:
Because we tried hard and failed != it's impossible.
The source to DMD is there. Feel free to try! I spent months trying to make it
work, and I learned my lesson.
Andrej Mitrovic wrote:
Why not do the same for templates? Something like this:
void foo(A, B, C)(A a, B b, C c)
constraint
{
isDynamicArray(a);
isIterable(a);
}
Consider:
void foo( A )( A a )
constraint {
isBar!A;
}
void foo( B )( B a )
constraint {
isQux!B;
}
Which error me
Andrei:
> Great. Could you please submit this as a bug report?
This shadowing is not detected :-(
struct X { int a; }
struct Y { int a; }
void main() {
X x;
Y y;
with (x) {
a = 2;
with (y) {
a = 1;
}
}
assert(x.a == 2);
}
Bye,
bearophile
On 11/29/10 3:25 PM, Manfred_Nowak wrote:
Daniel Gibson wrote:
"with" shouldn't be much of a problem anymore.
import std.stdio;
struct X{ int a, b, c;}
struct Y{ int a, b;}
void main(){
X x;
Y y;
with( x){
c= 2;
with( y){
c= 1;
}
}
writeln( x.c);
}
Do you
Daniel Gibson wrote:
> "with" shouldn't be much of a problem anymore.
import std.stdio;
struct X{ int a, b, c;}
struct Y{ int a, b;}
void main(){
X x;
Y y;
with( x){
c= 2;
with( y){
c= 1;
}
}
writeln( x.c);
}
Do you see the not "much of a problem"?
-manfred
Walter Bright Wrote:
> Syntax was not the issue. Back when we tried hard to make this work, there
> were
> many syntaxes proposed for it. The issue is the semantic conflation between a
> reference and what it refers to.
O.o
I don't believe, there's even single person in this thread, who will c
Andrei Alexandrescu Wrote:
> On 11/29/10 5:48 AM, Andrej Mitrovic wrote:
> > The licensing issues with DMD. I get the feeling we would have many
> > more contributors to the reference compiler and have bugs fixed at a
> > much faster rate than right now. Walter is already working at 110% of
> > hi
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin wrote:
Steven Schveighoffer Wrote:
My favorite in recent times is:
@tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations
should evolve that far.
What I liked about that is it is orthogonal to the const
On Mon, 29 Nov 2010 15:53:51 -0500, Jonathan M Davis
wrote:
On Monday, November 29, 2010 12:48:45 Kagamin wrote:
Steven Schveighoffer Wrote:
> lack of tail-const/immutable for classes.
>
> And no, Rebindable doesn't cut it.
As I understand, it's primarily issue for collections?
The lack o
On 11/29/10 3:02 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Syntax is the main issue in implementing this feature. Due to the
implicit nature of reference semantics for classes, there was no
syntax to distinguish between the head and the tail when qualifying.
FWIW I just thought of thi
On Mon, 29 Nov 2010 16:02:18 -0500, Walter Bright
wrote:
Andrei Alexandrescu wrote:
Syntax is the main issue in implementing this feature. Due to the
implicit nature of reference semantics for classes, there was no syntax
to distinguish between the head and the tail when qualifying.
FWIW
Andrei Alexandrescu wrote:
Syntax is the main issue in implementing this feature. Due to the
implicit nature of reference semantics for classes, there was no syntax
to distinguish between the head and the tail when qualifying.
FWIW I just thought of this syntax. It might work but it's not intu
Andrej Mitrovic Wrote:
> The licensing issues with DMD. I get the feeling we would have many
> more contributors to the reference compiler and have bugs fixed at a
> much faster rate than right now. Walter is already working at 110% of
> his abilities, at least that's the impression I get. I think
Steven Schveighoffer Wrote:
> My favorite in recent times is:
>
> @tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should
evolve that far.
On Monday, November 29, 2010 12:48:45 Kagamin wrote:
> Steven Schveighoffer Wrote:
> > lack of tail-const/immutable for classes.
> >
> > And no, Rebindable doesn't cut it.
>
> As I understand, it's primarily issue for collections?
The lack of tail-const is a particularly big problem for handling
On Monday, November 29, 2010 11:03:27 Andrei Alexandrescu wrote:
> On 11/29/10 12:56 PM, Michel Fortin wrote:
> > On 2010-11-29 13:08:54 -0500, Andrei Alexandrescu
> >
> > said:
> >> On 11/29/10 10:54 AM, Michel Fortin wrote:
> >>> The biggest problem I see is with generic programming. Say I pass
Steven Schveighoffer Wrote:
> lack of tail-const/immutable for classes.
>
> And no, Rebindable doesn't cut it.
As I understand, it's primarily issue for collections?
so Wrote:
> > What I can see now, mistakes are mostly syntactical like switch, auto,
> > const, rebindable, array ops, full slice, arbitrary-code-contracts
> > instead of single bool expression. Choice for round braces for templates
> > leads to slightly unreadable template code: foo!(params
On 11/29/10 1:49 PM, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 14:38:40 -0500, Andrei Alexandrescu
wrote:
On 11/29/10 1:35 PM, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 11:52:31 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On Mon, 29 Nov 2010 14:38:40 -0500, Andrei Alexandrescu
wrote:
On 11/29/10 1:35 PM, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 11:52:31 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
Ultimately I believe we need to make Rebindable
On 11/29/10 1:38 PM, Andrei Alexandrescu wrote:
On 11/29/10 1:35 PM, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 11:52:31 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
Ultimately I believe we need to make Rebindable palatable. That wou
1 - 100 of 145 matches
Mail list logo
