taking address of a string literal

[bronze man]

I think taking address of a string literal is some kind of "type transform",a syntactic sugar.

Now, we need follow code to return a *string

func f1()*string{
	tmp:="a"
	return &tmp
}

If golang support taking address of a string literal,we may use that code.

func f2()*string{
	return &"a"
}

I think taking address of a string literal is just like &[]byte{0} which malloc a variable which value is []byte{0}

I think I should also taking address of a int literal, taking address of a func literal ...

http://play.golang.org/p/aI6gKoGP_3

google groups topic: https://groups.google.com/forum/#!topic/golang-nuts/mKJbGRRJm7c

googlecode issues: https://code.google.com/p/go/issues/detail?id=6031

[Dave Cheney]

Before rewriting the language, can you please explain why you need a
pointer to a string.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[bronze man]

I have some code like this..

http://play.golang.org/p/AfslI-h2NB

func NewStringRule(s string)Rule{

tmp:=stringRule("abc")

return &tmp

}

Those code could be simple as : but it is a compilation error.

func NewStringRule(s string)Rule{

return &stringRule("abc")

}

[Dave Cheney]

You haven't explained _why_ you need this, only shown another way that
it doesn't work.

Why do you need to return a pointer to a string ?

[bronze man]

I have a type which base type is string.

A pointer to that type implement a interface.

So the factory of that type need return a pointer to a string.

I just want a syntactic sugar.

That's all..

[Dan Kortschak]

On Sun, 2013-08-04 at 21:52 -0700, bronze man wrote:
> I have a type which base type is string.
> A pointer to that type implement a interface.
> So the factory of that type need return a pointer to a string.
> I just want a syntactic sugar.
> That's all..
>

Why is the method on the pointer? If the string that's pointed to by the
*string is not altered, there is no need.

[Dave Cheney]

http://play.golang.org/p/bf0bRsXuXT

Works for me. Can you please show why this code cannot work for you ?

[Dan Kortschak]

I think he has this http://play.golang.org/p/U5U8-eBTt9

[Dave Cheney]

Right, but what does that buy you ?

[Dan Kortschak]

On Mon, 2013-08-05 at 14:58 +1000, Dave Cheney wrote:
> Right, but what does that buy you ?

I have no idea, that's why I asked him. The only reason would be if he's
'mutating' the string that's pointed to. I doubt this is the case
though.

For bronze man: strings are light, one pointer and one int.

[bronze man]

I can not change that underly string in some method on that type

http://play.golang.org/p/bZ9kgMz-Hc

That's why I need a pointer to a string to implement interface...

[Dan Kortschak]

So you are changing the string value with a method? Then let me
introduce you to

func stringPtr(s string) *string { return &s }

What is the actual thing that you want to do? So far all the code you've
provided works fine if the receiver is not a pointer.

[bronze man]

I found I wrote every method receiver as a pointer in my code .

http://play.golang.org/p/J37WBPoQSC

PS; I just found can not get an address of a type which base type is a slide of a interface.

http://play.golang.org/p/iGZkOEl0yc

[bronze man]

I want a syntactic sugar to reduce two line of code to one line of code.

func f1()*string{
	tmp:=StringMatcher("a")
	return &tmp
}

func f2()*string{
	return &StringMatcher("a")
}

On Monday, August 5, 2013 1:39:06 PM UTC+8, kortschak wrote:

[Dan Kortschak]

On Sun, 2013-08-04 at 23:15 -0700, bronze man wrote:
> I found I wrote every method receiver as a pointer in my code .
>
> http://play.golang.org/p/J37WBPoQSC

Sure. But you don't need to, so change it.

> PS; I just found can not get an address of a type which base type is a
> slide of a interface.
> http://play.golang.org/p/iGZkOEl0yc

No that's not the case. You can't get the address of something that is
not addressable. Make a var that holds the value and take the address of
that. But still, you don't need pointers here (unless the slice is being
altered).

http://play.golang.org/p/ka1MIze5Ik

Have you done the tour? If not, please do. It will be worth your while.

[Dan Kortschak]

I gave you that, and Dave and I have pointed out that you probably don't
need to use pointers for strings anyway.

[Jesse McNelis]

On Mon, Aug 5, 2013 at 4:15 PM, bronze man <bronz...@gmail.com> wrote:

I found I wrote every method receiver as a pointer in my code .

http://play.golang.org/p/J37WBPoQSC

PS; I just found can not get an address of a type which base type is a slide of a interface.

http://play.golang.org/p/iGZkOEl0yc

 

The return values from function calls and conversions aren't 'addressable' so you can't take their address.

This is because they may not actually exist in memory at an address that you can take eg. they might be in a register.

So you have to explicitly state that you want them in memory and give that memory location a name by assigning them to a variable.

In some instances the compiler could infer what you mean, but in others the inference would be confusing. 

eg. taking the address of a item in a map would have to copy the value out of the map first.

and taking the address of a function return value requires copying that return value.

By making it explicit a lot of the possible confusion is removed by adding just one line of obvious code.

--
=====================
http://jessta.id.au

[Carlos Castillo]

I generally make my mutable types as structs (even single element ones) because:

• Pointer receiver methods are easier to write to structs (fewer explicit dereferences)
• Mutating a field value makes more sense conceptually (to me at least)
• Clients are able to modify builtin-based types in ways you might not anticipate using the builtin's operators (strings not so much, but still...)
• There's no memory overhead to using a struct type

As a bonus, you can initialize such a type in the way you desire (one line vs two). Not that I see much problem with this, ever....

You could also make a New() function for your type if you must stick with builtin-based types, the compiler should have no problem inlining it for you.

[bronze man]

Good idea, A very good work around of this kind of problem..

Thanks.

Now I think this kind of syntactic sugar may be too difficult to be implemented in compiler.

[Rémy Oudompheng]

2013/8/5 bronze man <bronz...@gmail.com>:

> Good idea, A very good work around of this kind of problem..
> Thanks.
> Now I think this kind of syntactic sugar may be too difficult to be
> implemented in compiler.

Yes it's rather easy. It's not there because it was explicitly rejected.

Rémy.