FAQ
Hi I'm writing something along the lines of ...

type Field []byte

func Split(line []byte) []Field {
return []Field(bytes.Split(line, []byte{','}))
}

But I get an error like "cannot convert ([][]byte)(bytes.Split(line, []byte
literal)) (type [][]byte) to type []Field"

Is this just disallowed by the compiler, is a different underlying memory
layout the reason?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dan Kortschak at Feb 19, 2013 at 7:22 am
    Yes.
    On Mon, 2013-02-18 at 22:51 -0800, Rodolfo wrote:
    Is this just disallowed by the compiler, is a different underlying
    memory
    layout the reason?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 19, 2013 at 7:24 am
    That is to say, it's not allowed, though can be done with unsafe is the
    memory layout is the same (it will be in this case).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodolfo Granata at Feb 19, 2013 at 7:45 am
    Would it make sense (or be possible at all with the current compiler
    internals) for the compiler to check if the to-from types are essentially
    the same (eg: one defined on behalf of the other) to allow this? It would
    come in handy so you don't need to fall back to [][]byte for your data
    modelling and further allow adding methods, or even working up more complex
    composition:

    type Field []byte
    type Row []Field

    func (r *Reader) ReadLine() Row {
    ...
    return Row([]Field(bytes.Split(line, delim)))
    }

    Meh... there's probably just a better way to do what I'm trying to do
    without trying so hard :-)

    - Rodolfo

    On Tue, Feb 19, 2013 at 2:24 AM, Dan Kortschak wrote:

    That is to say, it's not allowed, though can be done with unsafe is the
    memory layout is the same (it will be in this case).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 19, 2013 at 8:05 am
    The last line can be done by (untested):

    return Row(*(*[]Field)(unsafe.Pointer(&bytes.Split(line, delim))))

    but unless you have methods on your Row type, why do you want to do
    this?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 19, 2013 at 8:06 am
    No, types are distinct by design. (This is useful so that you can't pass a
    JsonRaw to a function that expects an XmlRaw, even if they are both
    implemented in terms of []byte.)

    On Tue, Feb 19, 2013 at 8:45 AM, Rodolfo Granata wrote:

    Would it make sense (or be possible at all with the current compiler
    internals) for the compiler to check if the to-from types are essentially
    the same (eg: one defined on behalf of the other) to allow this? It would
    come in handy so you don't need to fall back to [][]byte for your data
    modelling and further allow adding methods, or even working up more complex
    composition:

    type Field []byte
    type Row []Field

    func (r *Reader) ReadLine() Row {
    ...
    return Row([]Field(bytes.Split(line, delim)))
    }

    Meh... there's probably just a better way to do what I'm trying to do
    without trying so hard :-)

    - Rodolfo


    On Tue, Feb 19, 2013 at 2:24 AM, Dan Kortschak <
    dan.kortschak@adelaide.edu.au> wrote:
    That is to say, it's not allowed, though can be done with unsafe is the
    memory layout is the same (it will be in this case).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodolfo Granata at Feb 19, 2013 at 8:14 am
    Yeah, sounds most reasonable... thanks.

    - Rodolfo

    On Tue, Feb 19, 2013 at 3:06 AM, Patrick Mylund Nielsen wrote:

    No, types are distinct by design. (This is useful so that you can't pass a
    JsonRaw to a function that expects an XmlRaw, even if they are both
    implemented in terms of []byte.)

    On Tue, Feb 19, 2013 at 8:45 AM, Rodolfo Granata wrote:

    Would it make sense (or be possible at all with the current compiler
    internals) for the compiler to check if the to-from types are essentially
    the same (eg: one defined on behalf of the other) to allow this? It would
    come in handy so you don't need to fall back to [][]byte for your data
    modelling and further allow adding methods, or even working up more complex
    composition:

    type Field []byte
    type Row []Field

    func (r *Reader) ReadLine() Row {
    ...
    return Row([]Field(bytes.Split(line, delim)))
    }

    Meh... there's probably just a better way to do what I'm trying to do
    without trying so hard :-)

    - Rodolfo


    On Tue, Feb 19, 2013 at 2:24 AM, Dan Kortschak <
    dan.kortschak@adelaide.edu.au> wrote:
    That is to say, it's not allowed, though can be done with unsafe is the
    memory layout is the same (it will be in this case).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 19, 2013 at 9:01 am
    I think this is a different issue. The OP is asking about legality of explicit conversion between []T and []D where D is type D T. This is only doable with unsafe, whereas your example is just a normal conversion.

    This is OK:
    http://play.golang.org/p/Igb-FhPvuy

    This is not (although can be done with unsafe):
    http://play.golang.org/p/qhW7kmyjvv
    On 19/02/2013, at 6:36 PM, "Patrick Mylund Nielsen" wrote:

    No, types are distinct by design. (This is useful so that you can't pass a JsonRaw to a function that expects an XmlRaw, even if they are both implemented in terms of []byte.)
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 19, '13 at 6:51a
activeFeb 19, '13 at 9:01a
posts8
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase