digitalmars.D - D affects others
- Russel Winder via Digitalmars-d (26/26) May 28 2014 Mike Hearn has started a thread on the Kotlin (*) mailing list extolling
- Wanderer (8/8) May 28 2014 It's very hard to keep up-to-date with all these successors to
- Russel Winder via Digitalmars-d (14/22) May 28 2014 I am not sure which languages you are thinking of here, there really are
- Andrei Alexandrescu (4/11) May 29 2014 Well it's quite a change of tenor compared to the early reaction.
- Walter Bright (7/9) May 28 2014 Yes, that's so-called "logical const". This has come up several times he...
- deadalnix (3/15) May 28 2014 It is probably a good idea to provide such escape in a safe
- Walter Bright (2/4) May 28 2014 If anyone wants to design such a module, please do so.
- deadalnix (3/7) May 28 2014 i have to say i'm not sure what people actually want :D I'll end
- Dicebot (4/6) May 28 2014 I am not sure it is possible to design such module so that it
- w0rp (7/19) May 28 2014 I'm a big fan of D's const, and strong static checking is one of
Mike Hearn has started a thread on the Kotlin (*) mailing list extolling the virtues of D's transitive const. Andrey Breslav (the leader of the Kotlin team at JetBrains) has made a couple of replies that I think may be interesting here: "As C++ and D show, const is not that easy. We'd like to have something like it, but it's hard to implement in a useful way" "D's approach is useful, but to make it work in Kotlin we'd need to know what's const in JDK and what's not. We are exploring the possible ways of knowing that, but it's not straightforward. Also, D's approach does not support lazy evaluation, caches of all sorts etc, that we think are crucial in application software. BTW, note that const does not come alone, but together with immutable, which we also would like to have in Kotlin, and which needs some more careful design wrt Java libearies, memory model etc" (*) Kotlin is a statically-typed language being created by JetBrains as a successor to Java. http://kotlin.jetbrains.org/ (**) Scala and Ceylon (and indeed Groovy) are other players in this game. (**) Kotlin, like Scala and Ceylon, is full open source. One day Java may also be, cf. OpenJDK. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 28 2014
It's very hard to keep up-to-date with all these successors to Java. Every half a year a new language appears, and it's always "better than all previous". :-( D's const feature is nice and clear. But what made me "fall in love" with D, is 'immutable' modifier. No inner mutable pieces possible, no need to copy defensively (or copy at all), no risk of data corruption, no matter how complex your data is. Very clever idea.
May 28 2014
On Wed, 2014-05-28 at 16:31 +0000, Wanderer via Digitalmars-d wrote:It's very hard to keep up-to-date with all these successors to Java. Every half a year a new language appears, and it's always "better than all previous". :-(I am not sure which languages you are thinking of here, there really are not that many languages seriously proposed in the Java-verse. cf. http://en.wikipedia.org/wiki/List_of_JVM_languages Of course in academia everyone involved in programming language research has to propose a couple of new languages a year to get funding. A very sad system and state of affairs.D's const feature is nice and clear. But what made me "fall in love" with D, is 'immutable' modifier. No inner mutable pieces possible, no need to copy defensively (or copy at all), no risk of data corruption, no matter how complex your data is. Very clever idea.We definitely like immutable :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> On 5/28/14, 10:05 AM, Russel Winder via Digitalmars-d wrote:On Wed, 2014-05-28 at 16:31 +0000, Wanderer via Digitalmars-d wrote:Well it's quite a change of tenor compared to the early reaction. Immutable has improved a frakton since, mainly thanks to Kenji's amazing work. -- AndreiD's const feature is nice and clear. But what made me "fall in love" with D, is 'immutable' modifier. No inner mutable pieces possible, no need to copy defensively (or copy at all), no risk of data corruption, no matter how complex your data is. Very clever idea.We definitely like immutable :-)
May 29 2014
On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:Also, D's approach does not support lazy evaluation, caches of all sorts etc, that we think are crucial in application software.Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
May 28 2014
On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:It is probably a good idea to provide such escape in a safe interface somewhere in the library, no ?Also, D's approach does not support lazy evaluation, caches of all sorts etc, that we think are crucial in application software.Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
May 28 2014
On 5/28/2014 1:49 PM, deadalnix wrote:It is probably a good idea to provide such escape in a safe interface somewhere in the library, no ?If anyone wants to design such a module, please do so.
May 28 2014
On Wednesday, 28 May 2014 at 21:22:36 UTC, Walter Bright wrote:On 5/28/2014 1:49 PM, deadalnix wrote:i have to say i'm not sure what people actually want :D I'll end up putting something together the day i need it, for sure.It is probably a good idea to provide such escape in a safe interface somewhere in the library, no ?If anyone wants to design such a module, please do so.
May 28 2014
On Wednesday, 28 May 2014 at 20:49:31 UTC, deadalnix wrote:It is probably a good idea to provide such escape in a safe interface somewhere in the library, no ?I am not sure it is possible to design such module so that it will be both sufficiently generic and reliably type safe. Can be an interesting challenge though.
May 28 2014
On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:I'm a big fan of D's const, and strong static checking is one of the reasons I picked up D a while ago. I think putting a little violation of the type system to accomplish something you really, really need, say in a trusted function, is a good way to do things. Most of the time, you don't *really* need to do those things.Also, D's approach does not support lazy evaluation, caches of all sorts etc, that we think are crucial in application software.Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
May 28 2014