On 12/21/2013 03:57 AM, deadalnix wrote:
Just watched this presentation :
http://www.infoq.com/presentations/functional-pros-cons
Skip to minute 28 to understand what we are discussing here about the
magical unique.
At minute 28 he starts discussing Monads using Dart-like syntax.
On Friday, 20 December 2013 at 22:40:16 UTC, Timon Gehr wrote:
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit now covers all cheap (== not rebind
indirections)
copies between same qualifiers
Kenji Hara
Just watched this presentation :
http://www.infoq.com/presentations/functional-pros-cons
Skip to minute 28 to understand what we are discussing here about
the magical unique.
On 12/18/2013 04:42 AM, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
...
Roughly speaking, this DIP just removes a language feature and changes
the syntax of another feature to something less descriptive. I think
implementing this
On Friday, 20 December 2013 at 08:42:29 UTC, bearophile wrote:
(We are bikeshedding a little.)
A lot actually, I just hope this gets implemented, whatever
keyword will be used.
On 12/20/2013 03:04 PM, Timon Gehr wrote:
The DIP breaks some existing, perfectly valid code without any clear way
to fix it.
const(int)* foo(...){ ... }
class C{
int* a;
this()const{
a = foo(...); // error
}
}
The actual workaround will be:
class C{
int* a;
On 12/20/2013 08:43 AM, Joseph Rushton Wakeling wrote:
On 20/12/13 01:41, deadalnix wrote:
If that is an extra learning cost, doesn't it make the semantic more
complex,
almost by definition ?
Compared to ... ?
As far as I can see, it's learning a small extra meaning of 'const' in a
context wh
On 20/12/13 09:42, bearophile wrote:
A new keyword is a flag that you have found something different. It makes it
simpler to learn.
[... ]
Giving different names to different ideas makes them less complex :-)
Seems to me there's something of a sweet spot to be found between minimizing the
to
On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin wrote:
On Thursday, 19 December 2013 at 07:31:28 UTC, ilya-stromberg
wrote:
What should we do if we decide that we need REAL `const`
postblit/constructor? I mean postblit/constructor that creates
only `const` object that can't be implic
On 12/20/2013 12:32 PM, Timon Gehr wrote:
On 12/20/2013 10:13 AM, Andrej Mitrovic wrote:
On 12/20/13, bearophile wrote:
A new keyword is a flag that you have found something different.
It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the
On 12/20/2013 10:13 AM, Andrej Mitrovic wrote:
On 12/20/13, bearophile wrote:
A new keyword is a flag that you have found something different.
It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the symbol name "body", but I can't use this s
Andrej Mitrovic:
It also steals a valid symbol name.
Someone has suggested to prefix it with a @.
E.g. there's tons of C code that
uses the symbol name "body", but I can't use this symbol
because it's
used in DBC. It's a keyword that's used in literally just one
feature, and it's annoying
On Friday, 20 December 2013 at 09:18:07 UTC, Joseph Rushton
Wakeling wrote:
On 20/12/13 10:10, ilya-stromberg wrote:
Would you like to be responsible for this decision?
I hope it's clear that what I'm trying to do is understand your
reasoning, because you have ideas and knowledge that are
di
On 20/12/13 10:10, ilya-stromberg wrote:
Would you like to be responsible for this decision?
I hope it's clear that what I'm trying to do is understand your reasoning,
because you have ideas and knowledge that are different from mine.
On 12/20/13, Andrej Mitrovic wrote:
> at least with
> asserts in the actual body I can add diagnostic messages)
Sorry that was wrong, "in" can be used for that of course. But I don't
see the benefit of in blocks.
On Thursday, 19 December 2013 at 09:52:15 UTC, Joseph Rushton
Wakeling wrote:
Unless there's a good application of a specifically
const-specific postblit/constructor, it seems to me that the
conflation in the DIP is helpful, because it simplifies the
process of writing, understanding and using
On 12/20/13, bearophile wrote:
> A new keyword is a flag that you have found something different.
> It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the symbol name "body", but I can't use this symbol because it's
used in DBC. It's a keyword
Joseph Rushton Wakeling:
As far as I can see, it's learning a small extra meaning of
'const' in a context where it's quite intuitive, versus
introducing an extra keyword which is used _only_ in this
context and which is not entirely intuitive.
A new keyword is a flag that you have found some
On 20/12/13 01:41, deadalnix wrote:
If that is an extra learning cost, doesn't it make the semantic more complex,
almost by definition ?
Compared to ... ?
As far as I can see, it's learning a small extra meaning of 'const' in a context
where it's quite intuitive, versus introducing an extra k
2013/12/20 Michel Fortin
> But what if your struct has a class-typed member:
>
> struct A {
> Object o;
> int* a;
>
> this(this) {
> a = new int;
> o = new Object;
> }
>
>
On 2013-12-20 02:07:32 +, Michel Fortin said:
But what if your struct has a class-typed member:
struct A {
Object o;
int* a;
this(this) {
a = new int;
o = new Object;
}
On 2013-12-20 01:31:03 +, Kenji Hara said:
2013/12/20 Michel Fortin
On 2013-12-18 03:42:38 +, "Kenji Hara" said:
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit now covers all cheap (== not
2013/12/20 deadalnix
> On Thursday, 19 December 2013 at 15:32:33 UTC, Kenji Hara wrote:
>
>> I think it is necessary small learning cost, to keep language semantics
>> simple.
>>
>> Kenji Hara
>>
>
> If that is an extra learning cost, doesn't it make the semantic more
> complex, almost by definit
2013/12/20 Michel Fortin
> On 2013-12-18 03:42:38 +, "Kenji Hara" said:
>
> http://wiki.dlang.org/DIP49
>> Improved points from version 1:
>> - Swap meanings of 'this(this) inout' and 'this(this) const'
>> - Inout postblit now covers all cheap (== not rebind indirections) copies
>> between
On Thursday, 19 December 2013 at 15:32:33 UTC, Kenji Hara wrote:
I think it is necessary small learning cost, to keep language
semantics
simple.
Kenji Hara
If that is an extra learning cost, doesn't it make the semantic
more complex, almost by definition ?
I'm also against adding a new mea
On Thursday, 19 December 2013 at 12:49:55 UTC, Francesco
Cattoglio wrote:
On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin
wrote:
void main()
{
immutable int* ptr = foo();
writeln(*ptr); // it is 0
GC.collect();
writeln(*ptr); // it is 1 now
}
Your proposal suffers from same i
On 2013-12-18 03:42:38 +, "Kenji Hara" said:
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit now covers all cheap (== not rebind indirections)
copies between same qualifiers
I can't help but notice
Kenji Hara:
I think it is necessary small learning cost, to keep language
semantics simple.
The semantics of the language is not simpler using "const", it's
the same semantic complexity. But it's a little less clear for
the person that reads the code.
Bye,
bearophile
2013/12/20 Timon Gehr
> On 12/19/2013 02:58 PM, Kenji Hara wrote:
>
>> 2013/12/19 Timon Gehr mailto:timon.g...@gmx.ch>>
>>
>>
>> Well, a constructor can be thought of as yielding a result. A const
>> method returning 'this' cannot return an 'immutable' object.
>>
>>
>> Constructor has no
On 12/19/2013 02:58 PM, Kenji Hara wrote:
2013/12/19 Timon Gehr mailto:timon.g...@gmx.ch>>
Well, a constructor can be thought of as yielding a result. A const
method returning 'this' cannot return an 'immutable' object.
Constructor has no return value in semantic level.
Conceptually
2013/12/19 Timon Gehr
>
> Well, a constructor can be thought of as yielding a result. A const method
> returning 'this' cannot return an 'immutable' object.
Constructor has no return value in semantic level.
> I do understand your rationale. What I am saying is that the DIP adds a
> wildcard m
On 12/19/2013 02:27 AM, Kenji Hara wrote:
2013/12/19 Joseph Rushton Wakeling mailto:joseph.wakel...@webdrake.net>>
And you have this(...) const (aka "unique"), which can be used to
construct both immutable and mutable instances.
It seems to me that this is a very natural relation to
On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin wrote:
void main()
{
immutable int* ptr = foo();
writeln(*ptr); // it is 0
GC.collect();
writeln(*ptr); // it is 1 now
}
Your proposal suffers from same issue. Although idea of unique
can be worthy, without escape analysis i
Maxim Fomin:
Your proposal suffers from same issue. Although idea of unique
can be worthy, without escape analysis it is another hole.
This seems the next important area of design/implementation work
to do on D :-)
Bye,
bearophile
On Thursday, 19 December 2013 at 07:31:28 UTC, ilya-stromberg
wrote:
What should we do if we decide that we need REAL `const`
postblit/constructor? I mean postblit/constructor that creates
only `const` object that can't be implicitly converted to the
`mutable` or `immutable`.
D is not C/C++.
On 18/12/13 22:53, ilya-stromberg wrote:
I understood your position, but it's bad analogy because we can have both
`const` and `unique` postblits/constructors (at least in theory).
I want to say that compiler can implicitly convert `mutable` and `immutable`
types to the `const` type, but we can
On Thursday, 19 December 2013 at 01:38:07 UTC, Kenji Hara wrote:
No, that's not merely syntactic choice. The 'const'
constructor/postblit is
a natural conclusion derived from the semantic meaning.
I tweaked descriptions in DIP to express it more clearly.
I disagree. It's the `unique` postblit
2013/12/19 Timon Gehr
> The natural interpretation of a const constructor is that it constructs a
> const object directly. Such a constructor could eg. initialize a field
> declared with a mutable type using some external const reference.
>
> void foo(const(int[]) a){
> // ...
> struct S{
2013/12/19 Joseph Rushton Wakeling
> And you have this(...) const (aka "unique"), which can be used to
> construct both immutable and mutable instances.
>
> It seems to me that this is a very natural relation to the existing
> interpretation of mutable, immutable and const variables by the langua
On Wednesday, 18 December 2013 at 22:26:32 UTC, Timon Gehr wrote:
The natural interpretation of a const constructor is that it
constructs a const object directly. Such a constructor could
eg. initialize a field declared with a mutable type using some
external const reference.
void foo(const(i
On 12/18/2013 10:11 PM, Joseph Rushton Wakeling wrote:
And you have this(...) const (aka "unique"), which can be used to
construct both immutable and mutable instances.
It seems to me that this is a very natural relation to the existing
interpretation of mutable, immutable and const variables b
On Wednesday, 18 December 2013 at 21:11:10 UTC, Joseph Rushton
Wakeling wrote:
On 18/12/13 21:11, ilya-stromberg wrote:
Sorry if I miss something, but I don't understand this analogy.
`const` means that original type can be `mutable` or
`immutable`, so both
`mutable` and `immutable` types can
On 18/12/13 21:16, Timon Gehr wrote:
On 12/18/2013 08:09 PM, Joseph Rushton Wakeling wrote:
Well, quite :-) I'm not complaining about the issues here, I'm
suggesting that inventing an extra keyword for the cases discussed in
these DIPs is not necessary, because the analogy and connection with
e
On 18/12/13 21:11, ilya-stromberg wrote:
Sorry if I miss something, but I don't understand this analogy.
`const` means that original type can be `mutable` or `immutable`, so both
`mutable` and `immutable` types can be implicitly converted to the `const` type.
If I understand DIP correctly, uniq
On 12/18/2013 08:09 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 19:40, H. S. Teoh wrote:
For this reason, it is better to write 'const' on the right side of the
function name than on the left
Yes, and it's exactly the practice I follow, although Ddoc replaces it
on the left-hand side ... :-
On 12/18/2013 06:33 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 18:20, Timon Gehr wrote:
Well, 'const' attached to a method is simply the notation used for
attaching
'const' to the implicit 'this' parameter.
Sure, but if you see a method:
struct Foo
{
const int bar() { ...
On Wednesday, 18 December 2013 at 19:10:07 UTC, Joseph Rushton
Wakeling wrote:
Well, quite :-) I'm not complaining about the issues here, I'm
suggesting that inventing an extra keyword for the cases
discussed in these DIPs is not necessary, because the analogy
and connection with existing use
On Wed, Dec 18, 2013 at 08:09:54PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 19:40, H. S. Teoh wrote:
> >For this reason, it is better to write 'const' on the right side of
> >the function name than on the left
>
> Yes, and it's exactly the practice I follow, although Ddoc replaces
> it
On 18/12/13 19:40, H. S. Teoh wrote:
For this reason, it is better to write 'const' on the right side of the
function name than on the left
Yes, and it's exactly the practice I follow, although Ddoc replaces it on the
left-hand side ... :-)
And also to always write `const(int)` rather than
On Wed, Dec 18, 2013 at 06:33:37PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 18:20, Timon Gehr wrote:
> >Well, 'const' attached to a method is simply the notation used for
> >attaching 'const' to the implicit 'this' parameter.
>
> Sure, but if you see a method:
>
>struct Foo
>{
On Wednesday, 18 December 2013 at 15:20:39 UTC, Kenji Hara wrote:
I think adding new keyword/attribute just for readability is
overkill.
Kenji Hara
We can use `unique` keyword as unique storage class of variables
in future if we decide that this feature can be useful.
It's not my idea, see
On 18/12/13 18:20, Timon Gehr wrote:
Well, 'const' attached to a method is simply the notation used for attaching
'const' to the implicit 'this' parameter.
Sure, but if you see a method:
struct Foo
{
const int bar() { ... }
}
... the instinctive interpretation of that is "This
On 12/18/2013 05:05 PM, Joseph Rushton Wakeling wrote:
On 18/12/13 16:59, Timon Gehr wrote:
It will be used to annotate a postblit that requires all fields with
indirections to be re-initialized with freshly allocated data instead
of a
postblit that is used during copying of a const object. (The
On 18/12/13 16:59, Timon Gehr wrote:
It will be used to annotate a postblit that requires all fields with
indirections to be re-initialized with freshly allocated data instead of a
postblit that is used during copying of a const object. (There will be no way to
define such a const postblit, becau
On 12/18/2013 04:47 PM, Maxim Fomin wrote:
On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
Kenji Hara:
I think adding new keyword/attribute just for readability is overkill.
Making the code more explicit and easy to understand, using the right
words, is rather important. So
On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
Kenji Hara:
I think adding new keyword/attribute just for readability is
overkill.
Making the code more explicit and easy to understand, using the
right words, is rather important. So I like @unique, that can
probably be re-u
Kenji Hara:
I think adding new keyword/attribute just for readability is
overkill.
Making the code more explicit and easy to understand, using the
right words, is rather important. So I like @unique, that can
probably be re-uses for another purpose.
What's worse than having many keywords i
I think adding new keyword/attribute just for readability is overkill.
Kenji Hara
2013/12/18 ilya-stromberg
> On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
>
>> On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
>>
>>> http://wiki.dlang.org/DIP53
>>> Redesign cur
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
Thank you very much -- this is going to be really useful.
On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara
wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings o
On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit no
On 12/17/13 7:42 PM, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit now covers all cheap (== not
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
http://wiki.dlang.org/DIP49
Improved points from version 1:
- Swap meanings of 'this(this) inout' and 'this(this) const'
- Inout postblit now covers all cheap (== not rebind
indirections) copies between sam
63 matches
Mail list logo
